Neil Brown: [00:00:00] We don't want to end up on the front page of the news. So, and we also have limited resources and limited time. So rather than responding to a deluge of alerts, we want to try and prevent the majority of misconfigurations up front and then allow the CSPM to come in on the back of that saying, Hey, we found some additional areas of focus for you to think about.

So what Kivera does in all of this is we are agnostic to the tooling. So no matter what tooling you're using, we're able to provide those preventative controls down to that parameter level, which IAM can't really get to. So with that approach, we're kind of capturing the misconfigurations up front and then we're allowing the CSPM to pick up any residual risks on the back of that and also provide assurance to make sure things are working as we expect.

Ashish Rajan: Have you heard of prevention is better than cure? But did you know that prevention is better than cure in the cloud world as well from a security perspective? So in this episode we're talking about how prevention could also happen within the cloud maybe sometimes with cloud native, but sometimes it requires non native solution In this episode, we'll talk about the importance of prevention use in AWS context as well as the wider cloud context. [00:01:00] How it's a bad idea to just rely on detection as the only way you do security because when you can prevent and have a paved road, why not use that to guide everyone who's using the cloud the right path instead of trying to detect and alert and throw all these things at it.

In this episode, we had Neil from Kivera to talk about the importance of prevention and how based on the experience he's had so far with AWS cloud, he's also felt that the need for prevention is a lot more higher today than anywhere else.

If you know someone who's working in the AWS space, trying to do prevention controls rather than detection controls, definitely share this video with them. But if you're here for the first time definitely check out the rest of the YouTube channel We talk about cloud security all day every day on cloud security podcast and if you like what you see definitely hit the like button and Subscribe and I'll see you next video.

Enjoy this episode with Neil from Kivera

Peace 

Hello and welcome to another episode of Cloud Security Podcast. Today we're talking about CSPP. But before that, Neil, for people who don't know Neil and Kivera, can you tell us a bit about yourself and how you got to where you are today, man? 

Neil Brown: Yeah, absolutely. So my name is Neil Brown. I've spent almost the last 10 years working in cloud [00:02:00] security, primarily with large enterprises and through that experience, kind of found a common set of challenges that customers weren't really able to solve for.

And about five years ago, I met my co founder, Vernon Jefferson. And so Vernon and I were working on the same customers and same client sites. And eventually we came up with. This idea to, to solve for this particular pain point that we were identified with customers. So about three years ago, we co founded Kivera. I'm the co founder and VP of operations at Kivera. And we've just recently announced our seed funding round as well today. So I'm really excited about that. Wow. And yeah, looking forward to kind of taking CSPP and sharing it with a broader subset of the community.

Which brings me to what is CSPP?

Honestly, it's a really good question. So CSPP stands for Cloud Security Protection Platform. It's a set of capabilities that stems from preventative cloud security. And what it's all about at the end of the day is trying to stop resource misconfigurations in cloud before they're deployed. Oh yeah. And it encompasses different sets of capabilities around securing, you know, cloud [00:03:00] resources, securing cloud data, but the benefits of those end up being you're simplifying your compliance outcomes within cloud, and also being able to move a lot faster when you kind of taking care of these things preventatively earlier on in the life cycle 

Ashish Rajan: so how different would be maybe I guess guardrails at the moment people talk about them. Is that because most of them are detectives? 

Neil Brown: Yeah. So there's different ways to implement guardrails. So the term guardrail is defined in many ways, depending on who you're talking to. Yeah. Some people will see it as a detective item, say, Hey, something's gone wrong.

We found a certain misconfiguration. Yeah. And we're going to send you an alert about that. That can be a guardrail in itself. Or the way we see guardrails is let's actually, through the true definition, actually prevent those things up front, as in stop people from going outside of those guardrails. Prevention is better than the cure. 

Ashish Rajan: And because I think, it's funny because you mentioned this, a lot of people want to do prevention, but seems like it's a, like what would be an example of a prevention thing that you can recommend?

Neil Brown: Yeah, absolutely. So if we think about something like creating a virtual machine, let's use AWS as an example. So [00:04:00] when I want to use run instances for EC2, what IAM will do, which is the native authorization language within AWS, it'll allow me to do things like, you have the permission to create an instance, or you have the permission to delete an instance.

What it doesn't do is tell me which subnet I'm allowed to deploy into, what security groups I can use, is my machine encrypted? Is it facing the internet? All of these things are a level deeper than IAM. And that's kind of where the cloud provider stops. So while there are 340 services in AWS and there's about 13, 000 different IAM actions, there's actually closer to 140, 000 parameters that you may want to control when you're actually deploying out to cloud.

So what Kivera does is it goes beyond just the service and the action where IAM stops and we go down to that 140, 000 individual parameters that can be controlled preventatively through Kivera. 

Ashish Rajan: So what would be I guess in a cloud context is there a service from the cloud provider that more than does this?

Neil Brown: So not quite, So your cloud native services across all three cloud providers usually stop [00:05:00] at that IAM action level. So Within AWS, your SCPs, your resource boundaries, your IAM policies, they're all going to stop at the IAM action. So they're only going to stop at that 13, 000 kind of number. It's probably closer to 14, 000 by the end of this conversation, the way they grow.

And the same thing happens in with RBAC in Azure or Cloud IAM in Google Cloud as well. All these services are stopping at the authorization of the actual action itself. But in reality, security and developers, we want to be controlling the actual parameters themselves. Because that's where really kind of rubber hits the road with compliance.

Ashish Rajan: Oh, so are we saying that at the moment is practically not possible for preventative to happen in the cloud because the IAM limitation? 

Neil Brown: Well, yeah, using native services, it's almost impossible. There's really no way that you can. But what customers do do is they look at different approaches to solving for this.

So in some circumstances, we may try and centralize every single deployment in the organization through a CICD pipeline. We've seen a lot of customers do this, particularly in large enterprises. So, for example, we want to use CloudFormation and we'll say everything that's deployed out to cloud is going to use CloudFormation and it's going to be deployed through this [00:06:00] pipeline.

What's going to happen then is the security teams are going to come in there and go, okay, and these are all the checks that we want to put in place and enforce as part of that pipeline. That really works great for maybe the first 12, 24 months of your cloud journey. Once you hit a certain scale and there's a level of maturity, you're going to have developers come in going, hey, I want to use Terraform.

Great. We have to go rebuild that whole pipeline again, or maybe I want to use a new service in AWS. Can you please enable it in this pipeline? It goes into a backlog and then 12 or 18 months later, that service gets delivered, but the team's moved on to something else in the meantime. So there's kind of a challenge there around if you are going down that preventative inline CICD kind of enforcement mode. Is how do we stay current and how do we keep up with the needs of developers as they evolve with over time? 

Ashish Rajan: Right, so and to your point, I mean, because I think I'm trying to paint a lens for both the people who are open to the idea of building one versus buying one, I guess, because there's always camps over there.

Neil Brown: Yeah, I think that's really the only approach to building is by centralizing deployments through a [00:07:00] CICD pipeline and I guess if you had unlimited time, money and resources, you could keep up with the demands of developers and keep up with the cloud providers. But in reality, we're always constrained in an enterprise or an organization.

So we don't have unlimited budgets. I mean, how many cloud security teams have you seen that feel like they're well funded and have, you know, the right resources behind them? Not many, and developers will say the same thing. So keeping up with this kind of, the pace of cloud, but also the pace of the tools that consume cloud is really challenging. 

Ashish Rajan: Right, so to your point, I find it interesting because I think every security person has a goal that I want to prevent this from happening beforehand. And the fact that the cloud security providers have a gap and they probably keep talking about IAM as a way to resolve this is probably not the right way.

So to your point, Centralizing in a CICD pipeline, would they get the ability to, when you say they will be able to prevent it and they would have to keep up with it if they know that, Oh, okay, so I only use five AWS services or five Azure services. Yep. Is that more of a practical approach to? 

Neil Brown: [00:08:00] Yeah, absolutely.

If you are starting out your cloud journey and it's very early days and you don't have a lot of workloads, you can absolutely go through this approach and most customers do. So what we're really looking at with these types of approaches is, we're going back to that conversation earlier about run instances for EC2.

We can enforce those controls at the pipeline level, but the challenge comes is when we want a team to deploy an EC2 instance that maybe is public because it's serving customer traffic. And so we need to go back to the pipeline, unpick that, and go, we have two different modes one for this team, and one for that team.

And in reality, most customers are using in excess of... 40 50 services within any of the cloud providers, their multi cloud, they want to support with the way that the maturity of cloud is today. We've got developers who are now not coming into an organization going, Hey, cloud's new to me. They're coming with a set of preconceived ideas and skills and ways in which to consume cloud.

So when you tell a developer, Hey, we're doing cloud at X, Y, Z organization and then you force them to go and deploy through this really rigid deployment mode, you [00:09:00] know, people turn over, we see a retention issues with that. We see a lot of developer frustration going, well, I'm not building on cloud. I'm building on this abstraction layer that you've just enforced in front of me.

So that's a really sort of challenging way that, you know, we're trying to enforce these controls. 

Ashish Rajan: And I think that's the platform based model is because it's a whole stream of platform engineers now platform this platform that platform. 

Neil Brown: That whole team is dedicated to supporting these CICD pipelines 

Ashish Rajan: Okay, so just point then people are thinking about building this and they're going okay. I can build a CICD pipeline and say Oh, okay. I cover only five services and I'm going to prevent people from deploying into, say, non Sydney region. So you can only deploy in Sydney or you can only deploy in the East Coast or West Coast. Yeah. But is that true prevention or is there another layer above that for prevention?

Like what would be an example there? 

Neil Brown: So I think that there you're talking about prevention for a particular persona within the organization. So one particular app team is going to have a great experience saying, Hey, everything that I want to do in cloud is taken care of by this one approach. But in reality, you know, the customers that we've worked with in the [00:10:00] past have 4, 000 workloads in the cloud.

And all those workloads are different. So at a scale, once you go beyond kind of, hey, it's my first baby steps in cloud, you're immediately hitting scale and complexity issues that kind of starts to break down this approach. And unless you're funneling a lot of resources and money into maintaining this platform, You're really kind of slowly getting behind the curve off the cloud providers.

And if you think about the way, I mean, we've been to many conferences in AWS and Google and Azure and you see that there's, you know, 20 services announced at some of these big conferences. How do we take those services and enable them in these models and You know, how do we let our teams use AI and ML in a fast time to value type of way?

And that's really challenging when you're constrained by a small number of people who are trying to solve this in a CICD pipeline. 

Ashish Rajan: Because I think another question people would ask at this point in time is also, Hey, I already have a CSPM, I do posture management. Isn't that prevention as well, in a way?

Neil Brown: Yeah, so look, CSPMs are really interesting. And we've implemented a number of these with different customers over the [00:11:00] years. The feedback that we get from the security teams is that knowing that something bad has happened, potentially minutes, hours, or in some cases days later, is not really good enough for certain risks.

Yeah. There's certain critical and high severity risks. If something's deployed publicly, you can guarantee that that's getting scanned and port scanned and within minutes, or seconds, sorry, not the minutes or hours it takes to trigger that alert. Yeah. And then we've got to think about, well, what happens?

What's the lifecycle of that alert? It's going to a team for triage, then pushed onto a developer team to go and fix that. And the actual remediation might take a significant period of time before actually getting to resolving the issue at its core. 

Ashish Rajan: Interesting. Well, after listening to this conversation, but for the few people out there thinking, Oh, I can still build this, what would you say is a good starting point for those people who are probably, and I mean, by the way, all the power to them, if they want to go and do it, right. Absolutely. Yeah. 

Neil Brown: Look, many organizations do. Yeah. Yeah. So 

Ashish Rajan: Cause you know how you said you guys are consulting before when you kind of noticed this as a pattern across the board before you kind of said, Oh, I'm going to start a company in this case, clearly it's not a one person [00:12:00] problem. It's like a many scale problem. 

Neil Brown: That's exactly right.

Ashish Rajan: What do you recommend them as a starting point for doing this? 

Neil Brown: Yeah, to be honest, what we've seen is that while in the early days of going down this road, it's, it's a common approach and a lot of people do it but over time it starts to become brittle and break down as there's complexities. So obviously what we've developed to try and alleviate some of this pain is by looking at, well, what are some of the needs of developers? They want to use the latest services. They want to feel like they're moving cloud native and they want to use the tools that best suit their workloads.

So they might want to use Pulumi for one particular workload. They might want to use CDK for another. They might want to use CloudFormation. Maybe they just want to go straight Java SDK for certain things. Give them the flexibility, but at the same time allow them to use all of those cloud services that are relevant to them as well.

So we want to use the latest SageMaker kind of Bedrock learning model that's been released. How do we kind of enable that really quickly? So that's the kind of developer experience. From the security standpoint, what do we want to do here? We want to look at it and go, hey, we don't want to end up on the front page of the news.

So, [00:13:00] and we also have limited resources and limited time. So rather than responding to a deluge of alerts, We want to try and prevent the majority of misconfigurations up front and then allow the CSPM to come in on the back of that saying, Hey, we found some additional areas of focus for you to think about.

So what Kivera does in all of this is we are agnostic to the tooling. So no matter what tooling you're using, we're able to provide those preventative controls. down to that parameter level which IAM can't really get to. So, with that approach, we're kind of capturing the misconfigurations up front and then we're allowing the CSPM to pick up any residual risks on the back of that and also provide assurance to make sure things are working as we expect.

Ashish Rajan: Oh, right. Oh, that's you. You're right. Cause IAM does not go into the, I guess a parameter level for you. Yeah. It can, you can say, Oh, I guess you can use actions and 

Neil Brown: action. And that's going back to the conversation we're having earlier where actions are 13 or 14,000 and the parameters are 140, 000. Yeah. And those are the things that we really care about when it comes to security.

Ashish Rajan: That's right. Yeah. Especially when you're dealing with 4, 000 plus services as well. 

Neil Brown: [00:14:00] Exactly. When you're at a. scale of 4, 000 workloads trying to enable that is really challenging. Wow. Okay. 

Ashish Rajan: Well, that's most of the technical questions I had. Where can people find you on the internet to connect about this?

Neil Brown: Yeah, absolutely. So I'm available on LinkedIn. Of course, you can email me as well. I'm more than happy to share my email publicly. So try not to spam me too much, but it's just a simple, it's just neil@kivera.io we'll be attending a lot of the major conferences. So we'll see you guys at re:invent.

We'll also be sponsoring a New York based summit, ONUG as well. So feel free to reach out on any of the socials and we'll love to connect. 

Ashish Rajan: Awesome. Thanks so much for coming on the show, man. I appreciate you coming over. 

Neil Brown: Thanks so much. Thank you. Love it. Thanks mate. 

Ashish Rajan: Thank you. Thanks everyone. See you next one.

‍