 My name is Rafiq Harabi. I'm living in Paris, France, and I've been in the cloud ecosystem since 2017. I've been working with Cystic since three years right now, helping customer in Middle East and Europe migrating to a cloud and adopting cloud-native security. For those who don't know Cystic, we provide a cloud-native platform for security and observability. We provide protection from source to run, and we are the company behind Falko, which is the thread detection engine for containers, Kubernetes, and Cloudia. Here is my LinkedIn, my Twitter, please, for free to add me. Okay, that's about me. I'd like to know a little bit about you. So my first question, who is here for the first time? Awesome, yeah, most of you. So my second question is, who knows one of those acronyms, CWPP, CSP, MSETRA? Yeah, a few of you. Okay, two of them. Oh, just five, three. All of them. Oh, yeah, okay, nice. You are on the right spot. That's what we'll be talking about today, so let's agree. So we have a package agenda today. I will start by describing and explaining those cloud-native security acronyms. Then I will go into the anatomy of the cloud-native application, the life cycle as well. I will describe as well the cloud-native security platform building blocks and the attack vectors that comes on different layer cloud containers and Kubernetes and containers. We'll deep dive into patterns and best practices and finally we go through the persona and workflows. So we have this package agenda. So the idea behind this talk, when you start coming either from development background or come from security and you start moving your workloads to the cloud, you got a lot of acronyms that is coming from conferences, webinars, blogs, et cetera. And you feel a little bit lost and confused. So the idea, we go through these acronyms, explain what they mean and then we explain the workflow that you have to implement. So talking about cloud-native application here, we have the main business value which is mainly the workflows that you're developing. You have mainly maybe some workload that you migrate through VMs to cloud plus containers, plus moving as well through serverless. And this is working on top of platforms. Kubernetes is the most common. You may be using some container as a service and it come with some, I would say, support or edge services like data. You want to start data either on like buckets, databases, management, kind of log monitoring, identity and access to provide access to your services and your platforms and finally network and security. So in order like to talk about security, you're not just securing your workload but you are securing the full ecosystem. This will bring us to the first acronym which is CWPP and CWPP Stanford Cloud Workload Protection Platform. We are talking here about the security of workloads either containers, serverless or VMs. And it's mainly about vulnerability management plus threat detection plus hard running. This is like a little bit of compliance. This is like the main thing is that you would be thinking about when you are thinking about CWPP solution. Yeah, and this is the main focus of CWPP solution. The second one is cloud security posture management and we are assessing here cloud security configuration mainly protecting the cloud control plane plus assessing the configuration of the instances and the managed services that you are using as a part of your application. So here you can see that this is the platform plus all the managed services except the identity of the talk later. So the next one is KSPM and it's stand for Kubernetes security posture management and it's simply a subset of CSPM. So because there is a lot of workloads moving to Kubernetes like it's becoming the defect to platform to run workloads. So we have like a kind of dedicated platform that and solution that look after Kubernetes and just think about it as a subset of CSPM. The next one is cloud infrastructure entitlement management. And here I'm mainly looking after my identity and access management, excessive permission, roles and service account that I'm not using or they are excessive misconfigured so on. So this is mainly around identity on access and we have as well cloud detection and response. And this is mainly more wider than the trend detection that we have inside the CWPP because we are trying to look from end to end. The CWPP is mainly looking on workloads but we are seeing like more and more sophisticated cloud attack that start from container going to the cloud services. And this versus of the idea here that I will have the unique solution that can track all this activity in a single solution. And the last acronym is CNAP and CNAP is stand for cloud native application protection platform and it's simply a combination of those solution CSPM, CWPP and CDN. And the idea here that you have like single solution that combine everything because integrating all this data that coming from these different sources make building protection more sophisticated. Yeah, in a national if you go like to the building blocks of CNAP platform we have as I mentioned CSPM or KSPM which is mainly about vulnerability management of those workload, misconfiguration, infrastructure as a code security as well. We have the important part which is coming at the very first stages and we have the threat detection and compliance framework. Something like you need to be compliant with industry best practices like CIS, benchmark or maybe you are in a regulated industry that you need like to be compliant with the FedRAMP or PCI or HIPAA and so on. So this is like the main CSPM part. CWPP all around workloads, vulnerability management, threat detection and runtime plus serverless security as well. SIEM all around the tech of excessive permission and finally CDR which is giving you a full spectrum of detection and response across your cloud environments. This is about the dos acronym. So in the next few slides we go through the attack vectors because it's really important to understand how we can attack those platforms and workloads and from there we can build our strategy. I would talk first about cloud attack vectors. We have like this is the building big building blocks of a cloud environment. We have this layer of identity network and control plan that is like the foundation of a cloud platform plus you have the data that is really like really useful for you plus server and serverless. And the first one is network bridges. This is like the most common when you create some services that are misconfigurated and attacker can use any scanning tool and scan your environment over the internet and get access. The second one is unauthorized resource access. A kind of example of bucket that you put it public with like private data. Data extracuration kind of putting for example database password inside container someone who access the container he gain access to these passwords and then be able to connect to those services remotely. Cloud security misconfiguration. It's all about misconfiguration of your service. For example, creating a Kubernetes cluster with public IP which is not mandatory for your environment. And finally, vulnerability exploit just deploying a container or workload on VM with vulnerabilities. So this is the most common attack vectors for cloud. Let's go with the Kubernetes attack board vector. The first thing is a misconfiguration of the Kubernetes control plane mainly the API server or the ETCD API when someone don't block the access from outside. So this is something that is really common. The second one is dashboard misconfiguration if you deploy Kubernetes with a dashboard that is open to public as well. Malicious containers image registry. Yeah, very common. Some people are pushing useful images but with malware and other sorts of like tools that they can you can deploy it by mistake and then they gain access to your environment keep reminding is like a big example here. Application with exploitable vulnerability as well and gain access to secrets when you deploy a workload and you're using, for example, Kubernetes secrets and then someone can gain access to that. And finally, Docker Damon misconfiguration when someone can hook on the Docker circuit and start doing some stuff. So for containers workload we have a set of attacks the most common are like having your container engine or the hosted that you are deploying Docker Bernabal or out to date. Secondly, Bernabal application very common exposed container engine that someone can hook into and secure image registry the same way that we have actually in Kubernetes. Privilege containers when a container can hook into the system onto the kernel because he has privileged access running as a root as a famous example. Mis-configured container. A container who'd be able to get into the container engine and as well privileged escalation on host. And finally and significant network oscillation when you can move from one container to another because you are not putting this isolation on the network policy. So that's the most common attacks I would say for a container. Okay, we were moving to patterns and best practices but before that, let's take a look at the lifecycle of a cloud native application. We have mainly five phase code build provision deploy and run and the code phase what we are producing. We are producing, let's say our business logic plus the dependency that they are graphic usually by developer. We are delivering a kind of manifest for my workloads like Docker files, application packages, hand charts, terraform for the infrastructure. Then I have this continuous integration which is mainly building my image and from there I'm provisioning my infrastructure and I'm doing some configuration. Then on the deploying side, I'm building a kind of either continuous deployment or continuous delivery pipeline. And finally on the run what I'm doing, monitoring my workload troubleshooting in case of issue and I'm doing a kind of incident and response. So this is like the big blocks for the lifecycle. So within the next slide, we'll take a look at the different controls and this is coming in iteration. So you need to implement a kind of continuous security and compliance. Yeah, within this slide, I will explain which is the different shake points that you need to put on different phase or like best practices. On the code phase, you can do a kind of drift detection based on the artifact that you are delivering. A kind like if you are like building a hand chart you can hook into, see if there is any of like container running as root, misconfiguration and so on. And you can as well block risky configuration mean that if there is something going to your github repository, you just scan it and then you can block that. On the build phase, we are building the image so we can do a kind of inline scanner, CI CD scanner, plus having registry scanning and host scanning for Kubernetes host. And we can prioritize based in use vulnerabilities. This is something I will explain in details next. Then we have the deploy phase when we have a kind of admission controller and I can block risky images and I can as well block risky configuration for my services. On the run phase, we have like three big building blocks configuration management, the CSPM compliance staff. So I can detect all this mean configuration from the runtime and I'm doing as well cloud inventory. So I need to see to list all my resources and be able to assess my resources against the risks I'm facing. Identity the same way on the entity, we are assessing all these resources and we are trying to do last least privilege. And as well, we do prioritization based on in use permission. So if one permission is not in use, I just like disabled. Trade detection for the cloud. We build some patterns on that and then we do workload runtime security. Yeah, one of the famous project you can use Falco. And on the incident response, you need to capture what's happened in order to do forensics. Plus as well block malicious containers or processes kind of a if I'm contained, my container is doing something a little bit risky. I can either like pose the container or like do a kind of sandbox or just kill the container if there is like some exfiltration of data and so on. So this is mainly what we have here as different checkpoints. So we go in detail as with the container in use vulnerability prioritization. This is really important because everyone who is in security field for a while, he know that there is a lot of like force putative and ingenuity. So you need like to prioritize what matter for you. And the pattern behind this that you have to prioritize and fix those packages that are really in use because every one of us know that developer like bring like define some packages that maybe they are not using. And how we are doing this, we are doing this with applying a multi-level vulnerability focus if the package is in use or not exploitable and has a fix. And we can apply this for both containers and Kubernetes host. How is work is let's say have an image here in my registry with three variable packages and I'm deploying this to my runtime and I can't see on my runtime that two of those packages are not loaded in the runtime. So the real risk here will be for me the CV that is in the runtime. Yeah, that's the real risk. How do I implement this workflow? The first thing I'll be like assessing all the vulnerability in the runtime. I will check if they are in use or not and from there I can't check if they are exploitable or not. If they are not exploitable, this is like let's prioritize it for me and the next step what I'd be doing I would check if they has a fix or not. If the vulnerability has a fix, yeah, I would go to my development team, send them the version of the package that fix the vulnerability and ask them to fix this. This can be via pure request or just via reporting. Yeah. On the other side, if this is something that is in use exploitable and I don't have a fix for it so my strategy will be to solicit the threat detection the threat detection team and try to mitigate the risk. The second pattern is container image signing. So actually we are, we wanted to fight against image tampering and wanted to be able and make sure that we are deploying images that coming from trusted source and the benefits behind these that you get, you get the images that are from trusted source, you make sure that there is no images coming from and non-source and you are implementing it kind of handover from development to production. So first of all, this step will be like developer iterating over like the dev registry, development registry. When they get a version that they are ready for QA, they will sign the image and they will push this to a QA registry and from there, we know that the QA team will be able to deploy this based on the origin plus the registry. So if it's something not coming from the development team, it will not be deployed to the QA cluster. Once the QA team do the job, what they will do, they will sign the image and then they will push it to a prod registry and the operation or like the SRE that are looking after the prod will be able only to pull images from this registry and sign it from the QA team. So if there is someone who is trying to deploy image from outside, it will not work. So this is something that really important to make sure that there is a safe handover through your CICD pipeline. The other pattern is gatekeeper pattern or mission controller. The idea behind this that I would like before deploying any workload or deploying any configuration or any manager service instance and manager service to make sure that I'm not deploying vulnerable images or images from entrusted tools to make sure that I'm not like harming my environment. So I would like maybe to make a decision based on image scan status if the image is vulnerable or not. The signing status is coming from trusted tools and from the right team for this right Kubernetes instance. And I would like as well maybe to check the provenance of the image. So we have like a multi-choice. We can take one of them or we can combine of them. And of course you need to make some exception. One of the famous exception if you have like some more clothes that are running as Damon said, that are agent and are mandatory for the platform or a kind of like if you are running a service mesh and you have the invoice site card which is vulnerable, you don't wanna like to stop deploying the site card because by stop deploying the site card you will like block your environment. So this is one of the things that you need to think about like manage exception for those for those workloads that are mandatory for your production. Yeah, the next pattern is to use base image and liar analysis. One of the famous that you can start with is using the RedHealth ecosystem catalog. And by the way, you can get updated images plus coming from trusted tools. They are updated regularly. And the second option is to start or like best practices to start with the minimal base image. You can see here that I'm scanning this Docker image node with this version. And I see here that I have like 15 critical vulnerability plus 153 high. When I'm moving from this version to the slim one, you can see here that I'm reducing my surface of attack of like my vulnerability exposure from 15 to one for critical and from 153 to three for high. So this is something that if you can use those like slim images, yeah, it will be something that you reduce your attack surface, help you to reduce your attack surface. Another thing that it's when you use like a base image, you can see here, for example, that they have this base image that used in a batch of workloads and there is a vulnerability there that being fixed. For example, here in version 1.2, it's easy here, like to rebuild my images with the new version of, by the way, I'm fixing a batch of images. So this is one of the best practices that you can use. And usually like teams, especially like platform teams, they will provide a subset or a set of images that they are mandatory. So developer cannot like start from an image from internet, but hey, this is my image for Java for node and so on. Yeah, the next button is to implement a continuous CSPM. So what I'm trying to do here, I'm trying to assess in an iterative way, all the miscafrigeration and address them as well in automated way. So from there, I can do a kind of drift detection and CGS remediation. So how this is work, we have a kind of like CSPM, CSPM capability that is running with my cloud accounts. From there, I'm continuously assessing the risk when I find something that is weirded. I'm opening a pull request to my infrastructure as a code security GitHub. And then I'm asking those guys responsible for this part of code to fix it at source. So the idea here that you can like apply a quick patch on your offline structure, but the problem if there is a new deployment, they will erase this patch. So the idea that you get the loop and the next time the team deploy a new version, this has come with the fix that you have to just set. Yeah, how is this working from risk assessed and prioritization? I have a list of inventory, then I'm inviolating my assets, then prioritizing them based on the risk and then I'm suggesting a kind of remediation. So it could be either I'm doing a notifix because it's high critical and I'm applying a patch or I'm adding this to my to-do list and maybe opening a pull request and send them back to developer or platform engineer. So let's move now to the persona and workflows. We'll go through this persona and then we'll go only see in the case how you implement those workflows for the best practices that we just exposed it. Yeah, first of all, we have the developer which usually is building like source, we have secure application and fixes with ability that coming back from production. We have the platform engineer DevOps and DevSecOps. This is like a kind of similar roles but it depends like change from our organization to another and they are mainly looking at building a platforms using infrastructure as a code, continuous integration and continuous deployment, as well policy implementation coming from security architects. On the security persona, we have mainly security engineer who is working in close with security architect and they are responsible mainly for defining policies and compliance plus trade modeling. And we have the SecOps which is looking after the runtime and he's handling trade detection and forensics. And finally, we have the CISU who just like getting like the score number at a high level. Yeah, here we can see like how this persona are going through the different life cycle. So most of them like the DevOps guys will be between deploy and run and SecOps mainly on the incident response and forensics. And of course the security architect would like to have like a kind of recommendation through the different phases. Yeah, the first thing that you can implement is like to put a scan on the CI phase. Like I'm just building my application here and then I'm running a scan. If I'm failing my policies or a descending back the image I will not push it to a registry. If this is passed, I will just push it to registry and then I will be able to deploy it. So this is actually the first stage in vulnerability assessment. And we can't combine these with registry scanner. And why we are combining this with the registry scanner because we can bypass the CI CD first. Not all the teams will be using a CI CD pipeline. Sometimes you have images that coming from partners and they are coming from vendors. So they are not coming through your CI CD pipeline. So actually what we are doing, we are continuously scanning the registry and we can as well add an extra step here which is every time I'm pulling an image from a public Git repository or from a partner or a vendor I will scan this image before pushing it to my corporate registry. So this is kind of workflow that you can implement to make sure that all the images that are in your registry that are up to date plus having those images scanned when it come from public sources. The second thing that you can add here is the workload identity and integrity. And here it's mainly about signing images. So I'm getting this picture in big picture here. So what you are doing, once you get the image in your registry you will apply a sign-in process. So in initial you have the public, the private key which is signing the image. So you have the image signed with the private key and then you have the public key that is running, pulling and running with the cluster. So once you want to deploy an image and then you have this public key on the cluster you can verify the origin of the image. On the other side, if there is someone who is trying to push image that is not sign it then he got rejected. So how it's working? You have the admission controller that is checking the scan status and the signature here. And from here you can see that I can solicitate like the scanning result or I can go and check the signature status. On the other side, this is on the pre-built. On the other side, if you are in the runtime you would like to discover zero-day vulnerability in running images. So you need to have this kind of continuous assessment of workload running in the runtime and how it's working. Usually deploy kind of a daemon set that is running with your hosters and this is assessed the vulnerability on the running container hosters. And then you're reporting this back either you send this to your team or you open a ticket for the team that is responsible for this specific image. Infrastructure as a code security we have seen the vulnerability part on the top. So the second part will be around scanning my artifact that's coming with the platform mainly Helm charts, Yamers files for Kubernetes and Kira form cloud formation and so on for cloud resources. So I have like a kind of two parallel built stage that are work here. From this perspective, I'm taking the infrastructure source repository, I'm scanning it. If this is fail, I will immediately notify the developer or the platform engineer and tell him hey, you need to fix this before going to the next step. If this is okay, I will merge this to my main branch or master branch and then I'll be able to deploy to deploy my infrastructure as a code. So actually what we are doing here you are blocking the vulnerability as source. You are not allowing this vulnerability to go to production but this doesn't prevent someone from changing some configuration in the runtime. So if you get this configuration, change it but someone throw UI, CLI and so on, you can implement a kind of drift detection here and from there what you are doing, you are getting this drift detection and then you are opening a pull request and from the pull request, the DevOps guy will review that and merge it and by closing the loop here we'll be able to make sure that this is being embedded in a source of truth which is my Git repository for infrastructure. That's all from me today. Two key takeaways. The first thing that cloud native security implementation is a team and collaboration matter. We saw through the persona that there is like different responsibility that is spread through different teams so you have to build this like a relationship and you have to make it automated and traceable. One of the best practices is to use infrastructure as a code plus GitOps because you will be able to track everything and track the history of all the changes and the second thing cloud native security should be adopted gradually. What I mean by that depending on what stage you are in some guys they are having their workloads going to production so they will be looking after mainly threat detection. Those who are still in early stage they will be looking after implementing security at early stage, shift lift and so on. So you cannot like implement everything within one shot so start by the most important use cases for your business. Yeah, I put further slides here for reading seen up cloud security blog from Cystik. There is a podcast from Annabelle on the Google cloud security podcast. Some reading from Gartner's and the Meteor attack for containers and you can find as well for Kubernetes. So that's all from me today. Thank you very much for being here. Yeah, I'm open to any question as well on Cystik booth so just stop me and ask me and please don't forget to rate the session and provide your feedback. Thank you very much.