 was a layered approach to cloud security. And I just wanted to give a brief overview of how this topic came about. As I talked to the community, users, end users associated with deploying cloud-native applications, the concept of security is always the last conversation, if you will. But at the same time, it's a very important conversation. And in that context, it is also very important to think about in-depth security. I've also seen different teams addressing the security problem for their cloud-native application deployments in a piecemeal manner. So what I wanted to do was provide the entire perspective on how security should be understood, and adopted, and implemented in the context of cloud-native. And when I talked about the security and its entirety, it also became very apparent that cloud-native applications and the cloud-native lifecycle and the workflow and the processes had some very, very distinct layers in it. So it also made sense to actually talk about security in the context of these layers. And that's what I would love to take you through for the rest of this session. So let's start off by talking about, oops, I'm sorry, let's start off by talking about what cloud-native application deployment actually looks like and what that means. So one of the cornerstones that we have come to recognize and realize in the context of cloud-native application deployment is the major focus of DevOps teams that are deploying applications very, very rapidly. And in that context, they are leveraging container-native artifacts, such as Docker files, to actually represent their applications and their constitute packages, build artifacts, all aspects of their system represented in a Docker file, which then actually references third-party images that could be easily leveraged in the context of software reuse and portability. And then these Docker files are used to actually in the next process, build a container image, which then gets resulted in the deployment of what we call containers as pods in a Kubernetes system, for example. And one other aspect of cloud-native application deployment is whenever I think about that, I think about scale. I think about the fact that a lot of these containers are highly ephemeral, that they can be scaled out to meet instantaneous demand, if you will, and then scale back to actually adjust for whatever the current demand for your applications are. So I think about scale. I think about the fact that they're highly ephemeral. So in that context, we have DevOps teams that are deploying at a very, very rapid pace, actually deploying infrastructure, tearing down infrastructure. And then they're always also treating their infrastructure as cattle and not pets. And what that means is any changes that they want to make to the infrastructure is represented as in infrastructure as code templates. And then whenever an update needs to be performed, the entire deployment, if you will, the container, if you will, for example, is actually destroyed and then reinstantiated with the new and updated artifacts. Now, let's actually move to security. Let's talk about security in the context of this highly dynamic environment. And what I've tried to convey in this picture is if you take the first four pod representations, if you will, but by the time security comes and says, oh, okay, I understand your security posture. I understand your application posture, and I need to come and secure it. So they come and secure it. But in the time that the security teams have come and they're trying to secure this, two new pods or two new sets of pods have been deployed or two new microservices have been deployed. So now security teams think that they have actually performed their job. They've got everything secured, but now they have a couple of assets that are not secured. So now let's think about the adversary. I mean, our adversaries are constantly evolving and leveraging sophisticated techniques to exploit every single avenue, if you will, to exploit our production resources. So now these adversaries can now attack these unprotected pods and potentially, for example, export data. And we've seen so many different vulnerabilities and attack factors that are being exploited, sadly, on a very, very regular basis. So the point here is the fact that you have DevOps teams that are moving very fast. You have security teams that are actually now struggling to understand the new dynamic environments to ensure that they have the appropriate levels of security. And the last part of that picture is that the adversaries are now using sophisticated AI and machine learning and automation capabilities to actually unearth exploit all the different types of threats and vulnerabilities. So you can see this is a constant and repeating pattern. So this in essence is one of the aspects on how we should be thinking about cloud native application deployments, the problems associated with security, and how adversaries can actually exploit a lot of holes in the armory, if you will. So now let's once again, make sure that we understand the entire application stack. So fundamentally at the layer, you'd have your typical access aspects of it where you have your load balancers, your network load balancers, application load balancers. You have a large number of subnets, if you will, where you're deployed all your hosts on top of which we can actually deploy either managed or self-hosted Kubernetes, the Kubernetes orchestrator for our container deployments. We also need storage, whether it's databases or cloud storage. So once we have all of these artifacts, we deploy our container orchestrators and one of the main avenues through which we can actually leverage and configure and deploy applications on the orchestrator is using the orchestrator API. So we have to, the orchestrator exposes the API server and a very rich set of functionality which are then leveraged by clients to actually perform various actions on the orchestrator. Now the next aspect of that is also we wanna make sure that we have isolation and one of the aspects through which that is facilitated in a Kubernetes environments is using namespaces. And then on these namespaces, we finally actually deploy the application pods. So once again, all of these different artifacts are what comprise the new cloud native application stack. However, with a lot of these very, very advanced system, it comes with a great level of complexity and with that complexity, it comes with a whole bunch of threat vectors as well. So before I talk about how we can secure it, we need to make sure that we have a very good understanding of what these threat vectors are. And I've tried to illustrate it here, but let's unpack this image here in a logical manner. So let's start at the bottom most layer, for example, the host. So sadly, as we know, our hosts are comprised of numerous application packages that are required to not only run different libraries, software programs, the orchestrator, et cetera, but a lot of these packages come with it a whole bunch of different host vulnerabilities, once again, which can be easily exploited by our bad actors and adversaries. Now, not only do these, the hosts come with a whole bunch of packages, but typically speaking, what we've also seen is the fact that these hosts come with a whole bunch of unnecessary OS packages that continuously contribute to expanding the attacks. So we also need to understand what are these packages, what are the vulnerabilities in these unnecessary OS packages and how we'll talk about how we can go about addressing. So that's the host, those are the packages. And then the next aspect is in the context of Kubernetes, it's this concept of master worker node configurations. So there are a whole slew of configurations which were not appropriately configured can actually expose your Kubernetes cluster to a whole slew of attacks. So we need to understand that particular threat vector. Once we have deployed your Kubernetes system, then the next level to actually address is the fact that you wanna make sure that your Kubernetes API, for example, is appropriately secured. So we'll talk a little bit more about that. And then when you talk about making sure that your API is secured, you also wanna make sure that you have this concept of you don't expose your entire cluster network to the internet and to the outside world to be exposed. So we also have to make sure that your network is not overexposed. The next aspect of all of these is the fact that now you're actually moving into the realm of your application containers. So you need to make sure that it's because of the advent of open source, as I mentioned, and I wanna put on my DevOps hat now as a developer, I wanna get my job done and I take a shiny new library. I don't wanna reinvent the wheel. So I import a new dependency in a library, but I have no visibility honestly as a developer as to whether this, by these binaries and these dependencies contain any kind of malware. So we need to understand whether there's malware present in these images. And similarly, we also have to understand what are the vulnerabilities that exist in a lot of these application dependencies. The next aspect is once we have now built the container, we also wanna make sure that we correctly represent how we want these containers to be deployed on your Kubernetes orchestrator. So that comes in the form of the Kubernetes application manifest. And the manifest now, as you can imagine, is a very, very powerful concept. So there is the ability for you, for us to make a lot of mistakes. For example, the security context. We also, very often we've seen that containers run as a root user. And so what that means is in the combination of the malware threat vector, some malicious code could actually do a container exploit with the root privileges, could actually do a container escape and actually exploit the entire cluster. So you can see how these threat vectors combine to really pose a large number of problems to your deployments. The second aspect is unfortunately more often than not, as developers are moving very fast, they need to test out, try out different types of things. And unfortunately, we see a lot of secrets actually embedded into your containers or also your application manifest. And as you can see, that is also a major threat vector that's right for exploit. So once that is done, we are actually deploying, let's say that we have to index all of these different threat vectors. And finally, a very significant aspect of cloud native deployment is the deployment, decomposing monolithic applications and deploying them as composite microservices. So the perimeter, if you will, for cloud native deployments is no longer your edge firewall, if you will. It's actually every single workload or every single microservice. Therefore, we wanna make sure that we can actually, even if there is an exploit, you wanna reduce the blast surface of that exploit and ensure that you have the right kind of segmentation from a zero trust perspective. So all of these aspects, as you can see, and a whole lot more comprise the components as well and consequently, the threat landscape for cloud native applications. So let's now take these threat dimensions and the threat landscape and put it in the context of how these threats actually manifest themselves. So a very, very common paradigm that is starting to be adopted now is the concept of shift left. And what shift left means is the ability to actually not bolt security on in the runtime, but make sure that security is incorporated throughout the application lifecycle and process. So in that, with that vein, let's actually move left and start from the infrastructure as code where more often than not, DevOps teams are actually representing all aspects of the infrastructure as code to leverage automation capabilities and really, really gain the benefit of agility, of deployment and reacting to different types of changes. But we've noticed that in the infrastructure as code, there are a whole bunch of misconfigurations in Terraform, cloud formation templates and ARM templates. And these misconfigurations, to give you a simple example, if you use Terraform to actually deploy multiple clusters in all the three different clouds, if you will, let's say AWS, GCP and Azure. But into your container cluster, you're actually exposing your access from the entire world on all ports or port 22 is fully exposed. And we know what the threat vectors there are and it's very easy for adversaries to exploit those threat vectors. So similarly databases, let's say you're configuring an S3 bucket, but if you have to make sure that those S3 buckets are properly encrypted, versioned the right level of ACLs associated with the IAM permissions. But the point here is that as we leverage infrastructure as code, this is also right for misconfigurations that could render your infrastructure highly vulnerable. And secondly, the second aspect of infrastructure as code is security violations and Kubernetes application manifest. I've also highlighted some, I've given you a few examples already, but let me just give you a few other examples where excessive privileges in containers in the security context are very easily exploitable. Shared namespaces between the host and the container, shared file systems, et cetera. And these are all specified as part of the Kubernetes application manifest. And if these are not appropriately addressed and fixed, they represent attack vectors in your runtime when you actually deploy your applications. So let's move on to the container image now. As we talked about it, the abundance of open source software that DevOps teams leverage is rightfully growing at a very, very dramatic pace. However, the DevOps teams don't have visibility into the vulnerabilities into these base container images. I myself performed scanning of a lot of these images and was very alarmed that a lot of the most popular base images that contain a lot of these base packages have very, very critical and high severity vulnerabilities that are right for exploit. So we need to be aware of these vulnerabilities in the container images, as well as in the vulnerabilities in the application dependencies. So not only the base images, but also in the dependencies that are pulled in to build on top of the base image. And you also wanna make sure that we are aware of any malware that is obviously present in the base image to ensure that those are appropriately interested. So once the container images have been built, the next stage in that process is actually hosting this container image in a container registry. And when, and your application manifest will actually reference that image to actually deploy these containers in your application runtime. So from a container registry perspective, we wanna make sure that there are no unsanctioned images that are actually referenced in your Kubernetes application manifest or deployed in your runtime. We wanna make sure that these images have, use of these images have been scanned very often that these images are not scanned. Therefore, these vulnerabilities precipitate throughout your life cycle into your runtimes. And you also wanna make sure that you're actually leveraging images that are appropriately signed to verify authenticity as well as the integrity of these images. Now, when we take these images, now we move into, we're starting to move into the runtime. Let's talk about the Kubernetes orchestrator. We talked about the fact that very often the Kubernetes orchestrator is misconfigured in terms of its API. The API, the Kubernetes API is very often completely exposed and you might not think that this is common, but this is more common, unfortunately, and it's been already exploited at some very, very widely publicized exploits. And secondly, not only are these APIs fully exposed to the internet, they also don't have the right level of authentication and they lack TLS-based authentication and therefore results in unauthenticated access. Another threat vector from a Kubernetes orchestrator perspective is exposed and insecure at CD access. And so at CD is the key value store that stores all the configuration for your entire cluster. So it's very important to ensure that that is appropriately secured. If not, it could have dramatic and radical consequences for your container runtimes. And I also talked about the fact that you also wanna make sure that you have the right level of isolation where you prevent the sharing of host namespace and the volume paths, et cetera. So these are all examples of attack vectors that precipitate in the context of the Kubernetes orchestrator. Now finally, from a runtime perspective, we talked a little bit about it already where there is lack of isolation. So that's a threat vector or when containers are deployed without the right resource limit so they can actually exhaust a lot of the CPU and memory and potentially render your system unusable or when you have the no runtime process file or network prevention. So what that means is you have unsanctioned processes or malware that can actually execute in your runtime, actually corrupt your files systems and actually contact command and control and malicious network domains to actually perform reconnaissance lateral movements and own your runtime environments. And so part of that network access is to make sure that if there is a lack of ingress and egress network protection, then your container, your environments are completely open to adversaries to perform various types of exploits. So what we've now talked about all the different, the concepts of what cloud native involves, the concept of highly scalable ephemeral workloads and the aspect of layers and the impact of all the different threat vectors and the way these threats actually precipitate in your environment. So what can we do to actually solve this? So I'd like to now present a visualization of the concept of cloud native layers. And I'd like to also wanna talk about how this particular diagram came about. I've been very fortunate to work as part of the six security working group at the CNCF and they had an initiative where we, as a group, we worked on a guide to provide comprehensive security and it was called the cloud native security white paper. And in that white paper, very appropriately, we divided up the entire cloud native landscape into multiple dimensions, as I like to call it. One is the cloud native lifecycle and the second dimension is the environment. The cloud native lifecycle, as we've all very come to recognize is built upon the aspects of the DevOps workflows where the developers are developing infrastructures code, application code and templates, et cetera, to actually deploy their application. So now all of these artifacts now move into the distributed phase where there are a whole sequence of activities that happen in the distributed phase where the containers are deployed, they distribute it to the application registries. And then finally, it comes to the deploy phase where there's a still further set of activities that are performed before these applications and microservices are actually deployed into the runtime. Now in the runtime environment is composed of the main aspects are, of course, compute, storage as well as the appropriate levels of access. So we've been able to divide up this entire cloud native landscape into these two dimensions comprising the lifecycle and the environment. And within that, the various layers. So what I'm going to do now is to walk you through how we can bring together security to actually secure our cloud native workloads, address all of the threat vectors that we have talked, I've talked about just now. And then apply it in the context of this cloud native lifecycle as well as the environment. So as we talked about it, the four big pillars of this cloud native application lifecycle are the develop, distribute, deploy, as well as the runtime. And what traditionally has happened is where application and DevOps teams are deploying software at a very, very rapid rate in the runtime and security teams have to bring to bed the appropriate security oversight. But now I talked about it. We want to shift left where we integrate security very natively throughout the application lifecycle into the developer phase, into the distribute phase, into the deploy phase, and finally, definitely into the runtime phase. So we're going to talk about each of these different layers and the implications of security across all of them. So what is security in the develop phase looks like? I mean, this is literally the first phase where DevOps teams are building out these artifacts and they're representing all aspects of their applications, which we've done for decades, but now also representing all the artifacts and aspects of their infrastructure as code. So this is where in the developer IDE, developers and DevOps teams are building infrastructure as code, Docker files, Kubernetes application manifest, and custom code. So what needs to happen is we need to bring security and early visibility. We talked about a lot of the threat vectors now, and that's why I mentioned that beforehand. But all these misconfigurations in infrastructure as code, all these vulnerabilities that potentially exist in Docker files and in application dependencies, all the security misconfigurations in Kubernetes application manifest, we need to provide early and instantaneous and contextual feedback to the DevOps teams in the develop phase, where they have a far greater appetite to actually fix a lot of these issues before it progresses through the pipeline. So one of the most powerful and tasks that DevOps teams does this, they make a pull request. And so what can happen now in the context of security is in the pre-commit hook, you can actually trigger the static analysis of all your code. You can perform the vulnerability scans for all the dependencies. You can scan your infrastructure as code templates, your Kubernetes application manifests, and actually report back. And if there's any failures that fail based on the compliance policies that have been established by your security teams, but you provide instantaneous and early feedback to the developers, and only when all of these different scans and compliance checks, et cetera, have been passed, do you actually commit the code to your source code management system and proceed to the next phase? But a very important aspect of this is now security is starting to be treated as a first class citizen. And you have early visibility into security violations, which can be appropriately addressed. Similarly, in the next phase, which is the distribute phase, where you're not actually using a lot of the representations of infrastructure as code and your artifacts, such as the Docker files, to build your container images or your virtual machine images or your serverless images. And as they move through the pipeline into your different types of registries, you're also just like you're actually doing your SAS testing, DAS testing. We also want to make sure that now you're performing your security testing. And the security testing can involve scanning all the container images for all the vulnerabilities that are present, identifying malware that are present in the images, performing all the infrastructure as code, security, and compliance scans to identify misconfigurations, and then making sure that you have the right configurations and the setting set in your Kubernetes application manifest. And once again, you can think about this in the context of a modern CI CD pipeline. And if there are any failures that are detected, the entire build phase, you go back to the drawing board, DevOps teams now have the ability to know what the failures are, how to fix them, and are able to bring together the right fix similar to any other bug fix that they would do in the context of an application. And then it moves to the next phase, which is the image integrity. So you want to make sure that you sign all your images. And if you want added level of confidentiality, you can even make sure that all the images are encrypted. You want to make sure that you check the integrity of these images. Once all of these different steps have been successfully completed, now we can move to the next phase, which is the deploy step. In the deploy phase, as I like to call it, this is where you get the opportunity to do a whole bunch of pre-flight checks. As we talked about it, we have signed these images. So you want to validate these images and the signature, both from an authentication perspective, as well as from an integrity, from modifications, and ensure that those are detected. You want to apply all your image runtime policies to make sure that you have the appropriate policies to enforce your enterprise policies, for example. And you also want to apply your runtime container policies, both your image policies, to make sure that only, for example, signed images, only images from registered artifacts or repos are allowed. And from a container runtime, we talked about ensuring that improper use of security context flags are not allowed, et cetera. So in the application runtime, now you want to make sure that you're constantly evaluating your deployment based on NIST and CIS standards that calls for best practices, assessments of your deployments. You want to make sure that you extend all your security checks to the host level, as well, to bring about visibility into any vulnerabilities that exist in the host, ensure that your compliance controls are also applied to the host, as well as from a micro-segmentation perspective. And finally, for the containers, you want to make sure that you have the appropriate part security policies, network policies to enforce the right level of micro-segmentation. And you also have frameworks that allow you to enforce file integrity or malicious file modifications you want to be able to detect it and to be able to perform remediations in terms of isolation of a container, only ensure that sanctioned processes are allowed to execute inside a container and even more fine-grained to make sure that you can even restrict the types of system calls that your container will execute. So all of these checks can be facilitated and enforced in the deploy phase. And then finally, security in the runtime phase. Now you've actually deployed all your applications. You have your orchestrator running. So let's talk about all the various aspects in the runtime phase, where you have the cloud environment, where you have your cloud orchestrators, you have your compute, you have your access in terms of network access as a storage. Then in the next layer, you have the workload orchestration, where you have the container orchestrator. You have the control plane, the container pod, the access in terms of your CNI, ingress, egress, your data volumes. So we've talked about a whole bunch of these, but it's important to highlight some of the salient aspects to make sure that you have the right level of RBAC enforce. You want to make sure that you have your admission controllers that are deployed to enforce your enterprise power security policies, for example, to make sure that you could have a policy admission controller policy, which enforces the fact that a container with too critical vulnerability should never be deployed into your runtime. From a network policy perspective, we talked about it, where you can use network policies to minimize your blast radius and to say your web microservice, for example, should never be talking to your database microservice. Pod security policies need to be enforced to make sure that you're not running pods with root users. You're not running pods with escalated privileges. You're not sharing your host namespace with the containers, et cetera. And then you also want to enforce your image authorization to make sure that images are signed, validated in terms of integrity, the hash, et cetera. And finally, now we're building up the runtime, if you will. It's the infrastructure layer. It's the orchestrator layer. And the final piece of the puzzle is the actual applications that are deployed as microservices as we talked about. And there is this need to actually ensure that you have the OS process control that I talked about, where what that means is you have a large number of containers running. It's impossible for security teams to now audit each and every container. I mean, that's just not humanly possible. So you want to make sure that you have automated techniques where you can only ensure that authorized processes are executing inside your containers. You can detect unauthorized processes. You want to make sure that your network access is very, very tightly controlled to make sure that your containers are not unnecessarily punching out to actually access command and control servers or even malicious, non-malicious domains. You want to make sure that you also have the appropriate levels of QoS. Make sure that you have the right levels of rate committing both in terms of CPU memory users resources as well as network. You also can also enforce memory protection. And a lot of new technologies are evolving around being able to leverage service mesh aspects where you can actually leverage abstracted services for a lot of these concepts that we talked about for example, authentication and authorization, encryption, mutual TLS, et cetera, that are being brought together by a whole bunch of technologies that are available by service mesh integrations. And the part that I particularly love about that is you can actually leverage these concepts without with zero change to your application code. And then you also want to make sure that you leverage a lot of these network service mesh kinds of access to limit the access to your applications and services. And then the one part that has been called out across all of these dimensions is auditing and make sure that you have the appropriate level of audit logs and log aggregation and the ability to actually perform log analysis is extremely critical for highly dynamic environments to be able to go back and actually recreate the environment around let's say when some kind of an exploit happen or a breach, et cetera, to be able to recreate the scenario to understand the root cause and be able to identify and detect and take the appropriate remediation. And finally, across all of these dimensions are the security foundations. I mean, security, as you can see, pervades the entire environment. But you want to make sure that your artifact registry, like your container repos, are appropriately secured. Each and every image that you deploy into your runtimes needs to be appropriately signed and validated. You want to have the right level of identity and access control across each of these dimensions. So it could be RBACs in the context of Kubernetes. It can be IAM for the cloud provider. You want to make sure that you have secrets are never persisted inside your containers. And you ought to be able to detect, identify that, and remediate that in your CI CD pipeline, for example, as we talked about by shifting left. You want to make sure that we've already addressed the need to do vulnerability assessments and have a good idea as to what the vulnerabilities are and ensure only containers that meet your vulnerability policies are deployed. But you also want to make sure that you're constantly evaluating your runtime environments for vulnerabilities and ingesting new threat feeds. And because of these highly dynamic environments, all of these aspects need to be automated. And finally, it's compliance. I mean, a lot of our enterprises come under various compliance standards. So you want to make sure that you have automated ability to actually have full visibility into the compliance posture of your deployments across all these three environments for your cloud deployments, whether it's Kubernetes deployments, as well as your application artifacts. So let's quickly talk about how do we go about securing the compute layer. And I've talked about a lot of this, so I won't spend too much time in each of these aspects. But let's start with the orchestrator, right? Because in the runtime, you want to make sure that your Kubernetes, the container orchestrator, I'm using Kubernetes because it's almost become synonymous with container deployments. But you want to make sure, and there are a whole bunch of well-known threats, and that's what I've called out here. But there are CIS benchmarks and Kubernetes benchmarks that call for various security controls that you need to ensure. So you want to, for example, you need to make sure that the API is not exposed to the internet. I talked about it. Ensure that API communication is TLS-enabled. You want to make sure that your CD cluster is not exposed to the internet, appropriately segmented, as well as to ensure that all control plane API requests are fully encrypted and authenticated. And as I mentioned, that was my next point there, which was to ensure TLS is enabled for its CD access. Similarly, you want to make sure that you have applying the right level of Kubernetes spot security policies where you disallow containers to run as root, or deny containers that require ex-privileges. I mean, those need to be the exception and not the rule. Allow only signed container images to be deployed and run in your environments. I also talked about resource requests and limits. I mean, these are all best practices that go a very, very long way in containing the attack surface as the blast surface of your environments. A very, very important aspect of it is to make sure that you've enabled your audit logs and sinks to ensure that you have full visibility into all the operations that are being performed in your Kubernetes clusters to be able to perform the necessary forensics and analysis if it's ever necessary. And finally, you want to make sure that all aspects, and I refer to this when I talked about the orchestrator, where all control plane authentication is appropriately authorized with the right level of authorization and authentication with an approved and verified certificate root of trust. So let's now talk about, we talked about in the previous slide, we talked about securing the compute layer, but now let's talk about the securing the containers in the runtime. In the runtime, you want to continuously scan for anomalies as I talked about it. You want to ensure that you have full visibility into the processes that are executing and at scale. So you only want to allow sanction processes. You want to monitor file system activity as well as malicious network activity. You want to make sure that you identify, detect and prevent malicious network access from a microservices and a trust perspective. The perimeter is now the microservice. It is not the entire environment. So you want to restrict communication to sanction services in order to minimize the blast radius. You can leverage network policies and other micro segmentation tools and capabilities to enforce this aspect of zero trust and sanctioned access. So the third dimension is we talked about image trust and content protection, where you can use a policy agent to control authorized access, only allows signed images with assurance of image provenance. You want to use encrypted containers if necessary for those kinds of use cases to protect your sensitive data. And finally, you want to leverage service mesh as appropriate because as I mentioned, it provides abstracted security services that you can bring to bear for your large scale deployments with zero code change. This also helps to eliminate implicit trust, encrypt all your traffic, and it dramatically and goes a long way to reduce your attack surface. And in the interest of time, I don't want to spend too much time on this particular slide, but the additional security considerations that have been called for, for example, in this cloud native security white paper that came out of the six security working group is storage security. Storage unfortunately doesn't get a lot of visibility, but you want to make sure that for your critical assets, you want to have the appropriate storage encryption for system volume protection. We talked about access, whether it's both IAM or from an RBAC perspective, you want to make sure that you have the right level of right facilities to help you manage your credentials using an HSM life cycle, being able to distribute keys, revoke keys, do a certificate rotation, et cetera, and to make sure that's highly available. Threat modeling is also another very, very important perspective that we need to pay attention to, to because you want to understand your end-to-end architecture, and once you've understood the threats, make sure that you have the right security primitives in place to address the threats as they pertain to your particular deployments. You want to be able to ingest new threat intelligence. Let's say, for example, known malicious IPs, new threat domains or suspicious command and control, you want to be able to make sure that you have the automatic protection for all the new threats that are being developed out in the world of their adversaries. Incident response capabilities, we talked about it. One of the main aspects here is you need to be able to adapt your incident response for cloud-native workflows. We make sure that you have zero trust where your trust parameter is not your entire data center, but it's the microservice and potentially the container in itself and only we have explicitly allowed communication patterns. We want to make sure that you're enforcing the concept of least privilege. And we also talked about constant evaluation of your compliance posture to make sure that you're leveraging all the best practices, recommendations based on various container and cloud-native standards that are available to ensure that you have the right levels of security controls. So in summary, the security for cloud-native applications and deployments needs to be automated. I've talked about it. It's all about scale. It's all about dynamism. It's all about highly ephemeral workloads. So traditional security controls just don't work. So we need to have it fully automated and integrated throughout your application lifecycle. That's the shift left, shift security left aspect. You want to have comprehensive runtime security controls. You want to make sure that you have the right level of image scanning. It needs to be fully integrated into your DevOps ecosystems. You want to make sure that you have the right level of segmentation, leveraging network and security policies and make sure that you're constantly applying and evaluating your environments for the right level of an adherence to compliance standards. With that, I'd like to thank you all very much. I know that there was a lot to cover there, but I'd like to now turn it over to Megan to potentially take some questions. Hi, Vinay. Yeah, you're welcome to just jump into the Q&A. It looks like we've got five questions in there. We've got about four minutes. If you want to take a look at those and see if there are any like to answer. Sure. Can I stop my screen and then talk about it? So one of the questions is, in shift left, don't we start putting security from the development cycle itself? Are we missing it here? Yes, and my apologies if that was not self-evident there, but yes, in the concept of shift left is diametrically opposed to enforcing security in your runtime. So you want to actually make sure that you are incorporating security into the develop phase, into the distribute phase, in your deploy phase, and highlight and identify security misconfigurations and problems before you actually deploy your applications into your runtime. Absolutely, that's a great question and thank you for bringing that up. And the next question is, which part of your pillar contains the SDLC phase? So the SDLC phase is actually, I would say, it straddles both the develop and the distribute phase where you're actually building your software, building your applications, building your infrastructure as code, Kubernetes application manifests all aspects of your infrastructure as code. And then you're actually now moving a lot of your testing, your system integration, SAS, DAST, as well as now your security testing into the distribute phase and making sure that all of those testing and making security a first-class citizen is actually captured across both the develop and the distribute phases. Where can we find a good hardened container image? I think, I would think there has to be an area where the cloud vendor does not allow for unsigned or malignant image. So that's a very good question. And so there is no simple answer to that unfortunately and that is why you have a lot of container scanning tools out there today where you can actually very, very seamlessly point these container scanning tools to your container image repositories and automatically scan those images. And then you have full visibility into your vulnerability as well as your compliance and security posture of those images. And that's where you, and this is once again, an activity that you could potentially perform in your distribute phase where the DevOps teams have built the container artifacts, the container image is now checked into your repository and now this container scanning tool can now seamlessly right from your image registry scan these containers to give you that level of visibility. And can we have a link to the white paper? Absolutely. It's also provided as a link in the slides and I'm Megan, would the slides be available to our attendees? We typically don't distribute the slides. We do put the presentation up on YouTube but if Palo Alto Networks wants to send out, I think you email out, they're welcome to include the slides there if that's something you're comfortable with. Okay. Yeah, absolutely. I'm happy to share that. So I would love to, I'm happy to share my email address in the chat if somebody would like to reach out to me and happy to chat about all these concepts. And so I had, there's a couple of questions in here specific to Prisma Cloud and I'd like to take those questions offline if that's okay. And, but I will definitely make a point to reach out to you to provide more information. Thank you so much, Vinay. It's been a pleasure to have you today. It looks like we are all out of time here but we will be in touch with the follow up information and the presentation will be available on YouTube later today. Thanks so much everybody. Great, thank you so much.