You. Good morning. Good afternoon everyone. Welcome in this session of Conf 42. Today, I'm excited to delve with you into increasingly important aspects of our digital world, container security. As we integrate more with sophisticated technology into our workflow, understanding and securing our containers environment has never been more crucial than today. So join me in this session of cracking the code of cloud security. We will focus today on protecting containers, infrastructure and workloads. Let me share with you a couple of striking statistics based on Aqua Security report. In 2021, about 40% of containers images are pulled from public resources. This fact alone underscores the far reliance and publicly available resources in our container ecosystems. There's a lot of resources out there, but what does it mean for security? While public resources offers a wealth of useful tools and efficiency, they can also bring inherent risk, such as potential vulnerabilities and unvetted content. Compounding these numbers with an issue of having 12% of containers were running as a non root user, which is a best practice in container security. So we can see that this is a notable point because running containers as a non root is a recommended best practice in container security. It significantly reduced the risk of privileged escalation attacks which can led to unauthorized access and control over containerized application. So as we progress today through our presentation, we'll explore what these statistics mean for your security posture, the challenges that they present and the strategies that we can implement to safeguard our containerized application. So let's dive in and start to unveil the complexity of container security. I'm today with you. I'm Fouadmulla. I'm a seasoned cloud security architect and the lead consultant. I worked with many multinational companies to secure their workloads and infrastructure, specifically focusing on the cloud and multi cloud administration. I'm CISM and CISP and SAS plus certified. Feel free to connect with me on LinkedIn. I'm happy to share with you thoughts and perspectives regarding security. Good, let's start with the agenda. So there will have a couple of main topics. First of all, introduction, the background of this presentation and the container security challenges that we might face that we face inherited from the container security nature. Cloud containers, vulnerabilities and container security in the terms of devsecops, enhancing security and going beyond the defaults. Also some kind of tools for automated vulnerability management that we can use and configuration management and network segmentation. A few points also best practices in container security. Let's get started first. Essentially, you don't really need containers to ensure security of your application. There's plenty of technologies and tools that you can use. However, by using containers wisely and many lines under wisely, you can really enhance your application security. Containers are not really prerequisites to say for securing application, but if you use it in a good manner, you can offer a runtime separation of your app. On host you can only deploy what you need. So there is a smaller attack surface, it's easier to set up, which means it's easier to patch. There is a predefined setup, so which can increase also consistency, which all the security personnel loves as overall improved security through their isolated nature, which can help in containing breaches, for example minimizing the impacts. However, this benefit is only realized if the containers are managed and configured securely. Adhering to best practices in containers security also to say you don't really need advanced security tools to start with containers. There's a lot of open sources, there's a lot of technology in there which you can use, but you really need to consider security to effectively use containers. Using containers without thinking about security is a recipe for a disaster. So always good to understand implement security best practices like let's say images scanning container isolation list privileges access zero trust principles are really essential to maintain the security and the integrity of the containerized environment. So challenges in container security first of all, there's a couple of points here, I just state a couple of them. There's a lot actually. First, the daemon attack surface. So it's inherited from the essence of the technology we are using. There is a potential vulnerability in the containers own systems. It's relatively a new technology similar to the virtualization on the VMS and virtual machines, but it's far behind in regards of vulnerabilities in this new technology, secrets management. And here, when I say secrets, I'm not only referring to credentials, passwords, et cetera, et cetera, but more also referring to the containers images itself. This has to be considered as also as a sensitive, and we'll see this afterwards in a couple of slides. There's also untrusted content risk. There's a danger of using, for example, compromised and vulnerable images. There's challenges in the growing environment of containers and also the ephemeral runtimes, which can have kind of special characteristics in incidence management and such, also in the lightweight isolation risks. So this can have also a lot of challenges to be considered. For example, when speaking of the daemon, only trusted users should have access to the API. We have to set also operation system permissions. We shouldn't expose this API unless it's really needed and using KLS and patching the system whenever possible. There's a couple of challenges actually in tracking and managing this on a large scale dynamic environment. Special limitation from WAFS and ids and ips in this regard, containers offer relatively weaker, as I mentioned, separation than VM. So this has to be considered in many scenarios of breakout. There's also security operations. Teams need to have some kind of a good pictures of what threats are going on this dynamic environment. So collaboration is really important. He has to come to the organizational culture to be coherent with this technology and to be empowering the team. So without help from SEC Ops, the build process could be really stalled due to allocate undetected vulnerabilities, since containers in the nature are ephemeral, meaning that they quickly spin out and really fast being destroyed. So it's really hard to detect and monitor changes on it, especially in complex systems. Also, it's sharing resources like cpus and then a lot of resources from the host. So it's really challenging to track, to have a track of records of what's going on on the physical system in my opinion to help really the SEC ops to help you look into the security tools that provide comprehensive visibility without interfering with your job. So the right tool should give you the sufficient metrics, numbers, logs that you need to properly monitor and measure the health. Don't forget also to observe the network as this is kind of, let's say no brainer in security and cloud security cloud containers vulnerabilities are here. Basically it's kind of a summary. This list can go on and forth. There's a lot of points that we cloud mention, but here are a couple of points. So the images images has to be dealt really as a sensitive information. These images can, if it's not tracked and scanned, it might contain vulnerabilities or any outdated components. Also, if these page images are not regularly updated or scanned, this can pose a potential security risk. There is also the insecured containers runtime configuration. I will touch about this a little bit further, but in essence default configuration is not secured containers and misconfiguration is kind of tight. There is no default by sorry, there's no secure by default setup in contest, so it has to be looked at from early stages. Usually we found vulnerabilities in the network segmentation. This is sometimes forgotten from the setup containers sharing resources on the network. So if one compromise, this can be potential privilege escalation or a container escape risk. Without request segmentation, the attacker can potentially gain access to other containers on the host system. Also the escape vulnerabilities I just mentioned orchestrator vulnerabilities that the orchestrators like for example kubernetes can have. Vulnerabilities that if exploited can really lead to a cluster wide impact. So it can have really hard and tough implications on your organization. This includes issues with API configuration and setup and authentication mechanism. Also sometimes dependencies can be kind of challenging or a challenging vulnerability. And container registry there is solution out there so keep track of what container registry you wish to use. But it's crucial to use trusted registry and scan the images for vulnerabilities of course, as well as logging and monitoring the gaps. Finally, using immutable and informal nature, this can pose really vulnerability of incident investigation and containers might be terminated and replaced before the investigation can be taken place. So that has to be in the incidence plan being somehow tackled as well as with the logging and keeping all the records that might be needed for such a case. So let me share with you kind of a little of insights of a cloud setup regarding contentious. However really you can use any technology here, I'm referring to the AWS cloud, but you can use Azure, you can use Google, all is good. Good to mention a couple of points here. So for example you can use the code commit service from AWS, but I really highlight the use of code guru for tracking if there's any credentials or any sensitive information that is embedded in the code. So you can have early stages check. You can also use tools on the dev team with the dev team, but this is also kind of a second or multi layer defense methodology. I would like to highlight. Well also probably possible to use the AWS secret manager here. You can see that we are using it for managing the secrets on the production and on the environment. Good to mention as well the use of for example the SAS scanning. Well there is a lot of technology that here I kept it open, but for example Dockerfile lint, it's a rule pays linter for docker files from Red Hat, can check the syntax and run semantics and check for best practices. And it's really customized with the Yaml language so you can just right away use it. Also another smart SaaS tool can be used is hadulint, which also you can get access to it. It's available and it really gives you really good insights regarding your container or regarding your image. Also you can have, well obviously you might have DAS protecting. This is on the interface level so your options is quite wide and open. And finally use the identity and access management on your cloud setup. That's kind of no brainer. And keeping your watch, cloud watch here, logging and checking all the logs on production and also as needed on the other environments to ensure integrity and track of records. This is in a nutshell. Typically when you are using cloud and especially with devsecops, we are in a race for deployment and for speed of pushing features. So it's a good practice to use infrastructure as a code. It can really streamline the process and keep the consistency in the environment. So how to enhance the security? Let's go a little bit beyond defaults and this is let's say a good takeaway from this presentation. So always the dockers. For example, built in sandboxing and runtime protection are a very good start. However, it's not a never complete solution, so always have to work a little bit further. Always the balance between developer flexibility and the security on the other hand, so find the right equilibrium between the ease of the developer and make a robust security protocols. Finally, managing images with care it's very good to highlight treat containers images as sensitive data, implement strict access control, jugular review and scan the content of images. So also how to enhance the security. Also beyond the default here I made a kind of like further points that were good to mention. Always use trusted paste images. So start with official minimal as much as possible base images avoid unnecessary packages, unnecessary tools to reduce the attack surface. Regularly scan for vulnerabilities so make this part of the pipeline of deployment and development. Implement list privileges access this is kind of essential and use immutable containers. So containers should be always immutable and disposable only deployed and they should not be modified. If any change needed, we replace the whole containers with a new one. And as much as possible let's use read only file system. So this will reduce a lot of potential persistence by malicious actors. Manage the secrets securely so use a good tool and good system to handle sensitive data and never hard code secrets. In containers images use secure network best practices, network segmentation and also good to mention resource limitation. So enforce some limits on your resources to prevent any DOS attacks and exhaustion on the system resources using policies and security context for example when utilizing orchestrator features like Kubernetes security context, pod security policies or equivalent in other orchestrator to enforce these security policies, use isolation as much as possible, especially when speaking with sensitive data. For example a strong mechanism can be used. The GVSR or kata containers can be really good tools or also you can use the native hypervisor based containers to isolate it on the host system. Configuration management will touch on in a couple of slides and of course keep the security embedded in your pipeline. So integrate security with checks, continuous development and deployment and make education awareness among the whole organization. A couple of tools here just to highlight for automated vulnerability management is really useful to use anchor it's an engine. It's an open source tool for image inspection and vulnerability scanning. Can access via GitHub. It provides a really centralized service for inspection and analyzes. So the anchor engine can be integrated with the CI CD pipeline to ensure the odd that only secure and compliant containers are deployed to production. Another also good tool is Claire, developed by Coreos. It's possible to get it from GitHub designed to scan containers for non vulnerabilities. What is good and nice that give you the ranking of the CVE so you can get the numbers and you can identifying security issues in early stages to be addressed. There's a lot of tools out there. Also good to mention AWS image scanners in private registry, so it can be also used for making sure that your images are scanned and in a good health before deployment. Few points regarding configuration management and network segmentation. I would highly recommend implement micro segmentation. So always fine grained network policies as much as possible control communication between your microservices and containers. Leverage the namespace so utilizing this in kubernetes to segment the resources, it's kind of a good boundary for the network policies. Also use network policies, for example especially in kubernetes to define which network configuration connection is allowed or blocked by default. Make block or deny for everything. Then start to add what you need based on your setup. Isolate sensitive workload, especially when dealing with compliance. If you have like a compliance issue that it's really helpful if you start from sensitive cloud workload isolated and then opening, let's say what you need from this workload to be processed or to be used so that can help you in your journey for compliance always. This can reduce the risk of exposure to other network traffic. Encrypt the container's traffic. Use tls to communicate. Make audits regular and periodic audits so it can give you some insights regarding also your policies. Good to mention. Also using the service meshes, it's really good technology. It can help you to go deeper on the level of containers. So for example istio or link card, you can use it for advanced traffic control monitoring between your services. Monitor these activities and integrate with your security tool. So if you have a WAF or technology you are using ids or IPS, you can use it for make another layer of logs and checks on your network. So let's recap few points here I'd like to highlight. First of all, containers can really improve your security if used wisely. So as we've seen, it has a really good potential has to be took into consideration all the setup beforehand. Docker is not secure by default and in a sense containers is not secured as a system is not secured by default. Never depend on the vanilla configuration. Always do your own setup and your own care of this technology. Always read images as a sensitive data. As we could see there is a lot of vulnerability and potential gaps that could be happening if you are not tracking your images. Finally, also follow network and configuration best practices. I shared with you a couple of them. There's a lot more so you can always keep track of these kind of best practices. Finally, use automated tools as much as possible to integrate your security into rescue into your DevOps pipeline. Finally, I wish you that no image of yours has any image problem. So thank you for joining me in this session and feel free to connect with me via LinkedIn and happy to be with you here. If you have any question, reach out to me and have a great day. Thank you for joining me in session and have a good day.