Prevent cloud misconfigurations and data leakage before they happen

I appreciate everyone coming out to the session today. This is a mild follow-on from an introductory session we gave yesterday, which introduced cloud workload security, which is a new product that we're launching within Cloudflare. So we'll give you a really brief overview of what the product is and what we've just launched. And we'll also spend most of today's session running you through a few demos around how we can prevent misconfigurations to cloud APIs, how we can prevent data leakage through common sort of exfiltration paths as well. So my name's Neil. I'm a Cloudflare 1 go-to -market specialist. And this is Vernon, who's a principal systems engineer. We both were the co-founders of a product called Kivara, which was acquired by Cloudflare recently. And what you're seeing today is the first integrated version of that product, which will soon be expanding out of beta. So just really sort of briefly to level set, what we need to understand about how we interact with the cloud provider is everything is basically an API call. So whether you're using your Terraform, Pulumi, whether you're orchestrating SDKs or CLIs, at the end of the day, an API call is being executed and sent to the cloud provider's API. So on the left-hand side, there's a request mode where you're actually configuring and saying what you need from the cloud provider. There's an execution step that happens, and then there's a deployment step when that change actually goes live into the environment. So a quick compare and contrast here. On the right -hand side is where detection happens. So if you're using a CNAP tool today, the Wizards, the Orcas, the Prisma Clouds of the world, a lot of that detection is happening on the right-hand side once the resource is already live and once the risk already exists in your environment. What we set out to solve as part of Kivara and now Cloud Workload Security was bringing that enforcement and control point earlier into the lifecycle prior to the execution time. So what Cloud Workload Security is, is it's trying to bring prevention in line and making sure that your detections are acting as a second line of defense with prevention happening earlier. So Cloud Workload Security is an inline inspection proxy that sits in between your developers and the cloud provider's APIs. Now, the way we do this and to achieve the flexible architecture that you need in these circumstances is we actually allow the proxy to be self-deployed into your environments. So it sits close to the developers. It sits close to your cloud provider, the initiation of those API calls. And it doesn't matter whether you're using any CICD tool, your Terraform, CLI, the SDKs, or even workloads making calls to other workloads in the cloud provider. All of these requests get proxied through this inline inspection proxy and it's applying policy in flight. So it inspects the request, evaluates against policy, and is allow blocks or logs the results that come out of that. Now, I do have AWS on the right -hand side here. We'll be doing some examples on AWS today. But this CWS as a product also supports all of Cloudflare's APIs. So as you're building on our dev platform or configuring your Zero Trust or application security suite, you can also use CWS to control those requests. We also have Google and Azure coming as fast followers. But today we'll be focusing on AWS. So a key point is that we just provide feedback with every blocked request. So policies at the API point are not on any particular deployment tool. Now, I'll quickly try and articulate this risk and then we'll have Vernon run through in a demo on what we're actually, so we can see it live. But really there's a particular risk that we come across in AWS quite frequently, which is if you have access within your corporate environment to read data, you may likely have access to exfiltrate that data using personal credentials. So let's have a quick look at this. So in this example, we have a corporate environment with an S3 bucket attached to it. Whether you are a malicious insider or someone who's gained access to the environment is trying to move laterally through and look for potential exfiltration vectors, or you're just an employee who's made a mistake. You can read this corporate data from the S3 bucket. You can copy it locally and read it to your own device or workload. And here is where things go a little bit off the rails if we're thinking about exfiltration. At this point in this corporate environment, we have an egress filter. And what that egress filter does, it could be a next gen firewall, it could be a proxy on the outbound that's looking at the different domains we're going to allow out to the Internet. One of those domains is start on amazon.aws.com because that allows us to interact with all of the cloud services. So here is where the risk really presents itself, which is when we actually bring personal credentials into the environment. So my own access key for my own AWS account, and I use that to put the object from my corporate environment into an external bucket or an untrusted bucket. Now, the challenge here is that at a network level, we can't see the tenancy information contained within those credentials. So we actually don't know what destination account it's going to. We also won't be able to use any of our SCPs or resource policies to control this because as we're on the device or workload, we are no longer beholden to any of those controls that are applied to your AWS environment. So you really have network level controls left. And unfortunately, in this circumstance, they weren't strong enough to protect. So we'll show you how CWS can actually prevent this type of misconfiguration. And I think it's best we just run straight into a demo now or our first demo, which will be demonstrating how we can potentially exfiltrate using personal credentials. So I'll hand over to Vernon to run through this next. Hey, everyone. Like I said, I'm Vernon. I'm principal engineer working on CWS. And I'll take you through some demos today. And hopefully the demo gods are on my side. All right. So let's go through this first example. And in my organization, say I'm a developer and I've been tasked to get access to a box and I've put a prompt into my favorite AI tool and it's given me back a configuration to try. So let's go ahead and try this out. So I'm just going to uncomment this. And basically I'm allowing ingress rings from the Internet through SSH onto my instance. And let's just see what happens. So I've pasted that in there. And basically what's going to happen now in this workflow, my CICD tool, in this case I'm using Buildkite, and it's going to pick up the job and it's going to start running. So you can see here it's picked it up. It's going to do a terraform plan and then do a terraform apply. So while that's running, I'll take you through the UI and what does CWS look like in the Cloudflare dash. So the first thing is we've got a deployment. So this is your proxy deployment and your configuration. So in here you'll have the proxy. You have some policy sets, which is just a group of policies. And you have a domain ACL, so which URLs you want to allow through it. Basic auth credentials, deployment settings and so forth. And the main one here, which is quite interesting, is the workload. So how do we identify traffic coming through the proxy? So for example, in the first one I've got non-production accounts. So I can actually define the traffic that's coming through as AWS, but I can even go further into it and create filters, which say that all the OUs, all the non-production accounts in my non -production OU will be classified in this workload. So as requests come through the proxy, we might have a policy set that is for NIST controls and here I've got my workloads defined. So in this one, for example, it's going to pick up all my non -production accounts plus the build card agent that's running as well. And then all the policies that I want to apply, so enforcing the data perimeter. And in particular, the one that we were just trying, which is the EC2 security group. So what I should see when I flip back to Buildkite once it's done, is basically a policy that's been applied which says that I can't allow ingress from the Internet. I need to use a private range. So if I switch back, I can see that the build's failed. If I click into it, you can see here that it tried to create this security group rule with 000480. It failed. So CWS got in the way. It said the request has been blocked. It tells you the provider, the service and the action. But you want to know also in context of the build what actually went wrong. So if you scroll down a bit further, we've got a tool here, the CWS CLI that will actually tell you why it failed. So developers, as they see this block, they actually know how to go and fix it. So in here we can see that the data perimeter policy was allowed. So it's a credential that I'm allowed to use and I'm talking from an account in my organization. But when I tried to create the security group rule, it failed because of it's open to the Internet. So if I go back to my rule, change this to private range, commit that, what we should see now is the build pipeline will run again and hopefully it will go through. So that's an example using a CICD workflow, but not all organizations might have this for all their environments. This is maybe a production workflow and a lot of developers are using tooling from their laptops as well. So how does this work when we actually use it from our terminal, for example? So let me just switch this back. So let's just do an example of creating that security group rule again, but from my laptop. So from a terminal. So if I run this, again, it's blocked. It's the same one rule that's going to apply it no matter what. So in this case, this is using AWS CLI. If I was using the Python SDK or whatever it might be, it would block it in the same way because we're blocking at the API level. If I go and change that back to the private range, then it already exists, but if I did it to 168, for example, it's blocked as well. And you're doing CIDR math on the fly? Trying to, yeah. So that goes through. So let's try a different example where we've got an S3 bucket. So here. So we actually did a second demo first, which was just showing a misconfiguration, which is not an issue. So using a public range for opening on port 22 SSH. This example that I was just touching on before around the allowed and untrusted accounts, that's the demo that Vern is just about to show you. So the exfiltration one is now. We just showed you a misconfiguration demo. So also in this environment, we've got an example of trying to copy some important data to a S3 bucket. So if I try to change the bucket name to just something else, so bad bucket. You can see that it fails. I have a policy set up in my environment that says that I can only talk to firstly buckets that I'm using a credential that's in my organization, but then also a white list of buckets that I'm allowed to talk to as well. So in this case, I haven't put the right bucket in. And if I do put the right bucket in, so in this case, it's actually called prod artifacts, and I try to copy it in there, then this will work. But another example of that and what Neil touched on was personal credentials as well. So in this environment, I've got my personal profile loaded up as well. It has my own personal account that belongs to me. If I try to copy that as well, that also fails. So in the policy, we're actually looking at credentials that are originating from an account that we own, but also white listing the bucket as well. So it's just a pure, like in the regular policy that you write, you can have a white list there that says all the trusted resources that you're allowed to talk to. So we ran through a few things there. One was putting an object to a corporate account, which was allowed, putting an object to an untrusted account, which was blocked. On the left-hand side is a little bit of a simplification of what the policies look like. We basically have identities, which is what Verna touched on earlier with deployments. You can effectively scope any API request to an identity or a deployment. And what that's doing is it's saying, based on who you are, you get a specific set of controls applied to you. So if you're in a B2B part of the business that has a lot of interactions with external trusted providers, you can have a different allow list of buckets that they're allowed to access, or a different allow list of AWS accounts they're allowed to access. You can kind of slice your traffic as you need it, depending on what it is. The other thing you'll see here is we have something called an action, and here it's S3 put object. We've effectively mapped every single AWS service and API that exists in the SDKs, and we support those as policies. So as soon as a new AWS service gets released, reInvent's coming up in another month or so, we're about to see a deluge of different releases. All of those are supported out of the box immediately, because as soon as it's in the SDK, we then support it in the proxy as well. So the proxy has an up-to-date map of what each of those actions are. And in the next, I'll just quickly run through this, and I'll show you one more example in the slide where, which is, here is just an illustration of what Verna was showing you through the demo, where you have say, Terraform and the Bodo3 SDK, which is what the CLI uses in Amazon. They look different at source and in code. So if you're trying to apply policy and infrastructure as code, shift left policy, you'll have to write two different rules, depending on what you're actually accessing on Terraform or through the CLI. With CWS, because it's the same API call, we're applying that same policy once. And the real challenge here is that IAM and SCPs and RCPs are all great tools to apply preventive boundaries. But things like IAM are really controlling who can access something and what they can actually change. They can't go one level deeper to the parameters of that particular call and say, hey, this port source or protocol is the thing that we allow or want to control. And that's where CWS comes in. It goes one level deeper. On the EC2 security group example that we just gave, on the left-hand side, I'll just draw your attention to the action and the policy. In something like this, we could almost expand this as well. We could say that for modifications of the security group as well, that we want to apply a preventive policy to those through the same single policy. So you can't create a security group with an any-any. And you can also not modify an existing security group and add that rule in as well. And that can all be part of one same policy. Similarly, the policy language is so extensible, we could also go, instead of just IPv4, we could also add IPv6 in there. So one policy can take care of creates, updates, and IPv4 and 6. So with the last sort of three and a half minutes, I'm happy to take any questions that may have arisen during the demo or the slides. Anything that sort of comes to mind, happy to answer any questions. Otherwise, we are now available in open beta. We have very generous free tier limits. So please go ahead, give it a crack, download it. You can run it locally on your own device or you can run it in cloud as well. And it's free and open and ready to be used. Thank you everyone for your time. If you would like to contact us directly, I'm nbrown at Cloudflare.com. I'm happy to take any questions and continue the conversation afterwards. Thank you. Thank you.