 Hello everyone. I hope that everyone is doing fine and is safe. I'm very sorry, Evan. I'm not able to join today. I really wanted to, I really appreciate and enjoy the open source community and particularly for Sasia. Unfortunately, the circumstances don't allow, but we're lucky in a way. We're in 2020 and technology allows us to be anywhere remotely and recall. So I just want to join it. It is this opportunity to share with you how cloud native and containers really have security moving forward. But before we delve into the topic, I just want to introduce myself. My name is Jordan Walter. I am lucky enough, as it were, again, in a generation where we can be proud to be digital native. I'm born with a computer, more or less. I have a degree in business and in engineering. But really, in the last 15 to 20 years, I've played with a number of role developers, system engineers, particularly Linux security for the last 15 years. And so a lot of my discussion today would be really blended and showing and focusing on how we can leverage those tools that developers, IT, system engineers, and use every day. How can we use them to improve security? And today, Phil Ciso at Piloto, which has been acquired by VMware. So the name will change quickly. And so as a Phil Ciso, I had companies, large companies, of course, with this transformation of cloud native, I have some leverage and embrace those technologies to improve their security. So I want to share this with you, because I do believe that there is a lot of opportunities here to fix the kind of challenges that we're having in the security landscape today. VMware might not be top and foremost when it comes to open source, right? No. If you ask what companies are open source, VMware is known for this year. So it's not really that known that they are absolutely big contributor to open source and open source is a massive part of the roadmap of VMware. Not for the least that if you follow the news, our CEO then has announced that the strategy of the company is Kubernetes. And so VMware is the second biggest contributor in terms of code to Kubernetes today. So it's really a big commitment in open source. As part of the acquisition of Piloto, Piloto was also the creator of Spring, which most developers among you would know, and Cloud Foundry. So these are the three very big projects that VMware is committing into maintaining fostering, making absolutely developed further. There is also a number of other projects that VMware has been releasing in open source, has been contributing to, I want to enter the details, but really VMware, you should be seeing VMware as a net contributor and an advocate of open source and this is why we're here. So today we'll be talking about cloud native. We can't talk about cloud native security without actually looking at what cloud native here. Unfortunately, still today, people have a lot of variations in the definition of cloud and cloud native. So we'll delve into this definition first before looking at the security of containers and how cloud native security really helps security moving forward. So let's start. When you ask people what cloud is or what cloud native application is, you typically would receive a lot of different answers. But lucky for us, some organizations have done a very great job in defining it. So if you look at the NIST definition of what the cloud is, it's really about being able to deliver on-demand resources, the network computing storage on-demand, being able to create them, destroy them on-demand rapidly with minimal management of the heads. And that's really a massive change we've seen in the last 10 years, in the adoption of those cloud technologies, on being able to go click, provide resources. And that really changed also the way we deploy your application and we think of application. That's what cloud native application is about, is the leverage, the ability to provision and destroy resources on-demand and easily to develop applications that are scalable, applications that are adapted to this environment and to go develop faster. So this is why the core of cloud native is about lucid temporal applications, provisioning automation, microservices, because this is the core of how do you leverage the ability of those cloud technologies to develop application better. Really, if you scratch the surface, that means that the public cloud, as a cloud, gives you any resources anywhere in a matter of minutes and cloud native allows you to push an application anywhere at any time. But all of it is really software-defined. The core of what cloud is, is software-defined application, software-defined network, software-defined infrastructure. And unless you really think of everything being software-defined, you really are challenged in the cloud and really enable you to do scalability, dynamic workloads, really on-demand. And the core of cloud native is really containers, right? If you look at cloud native applications, they need to be distributed, they need to be consistent, they need to be deployed easily, and that's what containers give us, give us a way to deploy lightweight workloads, portable anywhere consistent across the workloads. But really, is it secure or not? This is what we want to explore. If you look at containers, usually people ask and have a discussion around security of containers. So there's two types of security you need to look at. On one hand, the security of the container. Are you building a container that is secure, is a pre-ducial, or is a pre-ducial tax surface that is well configured? But once you go to cloud native application, actually we get a lot of opportunities to receive the way we do security thanks to microservices and containers. And that's really what I want to explore and what we need to do into cloud native security. So let's look, container security. In a traditional environment, we provision operating systems and then we build anything manually on top of it. Networking, runtime layers, makershift. Everything is customized because your application demand different settings and different configuration. This is a really overhead we're dealing with today. In terms of container as a service or platform as a service, you really need to think as provisioning, automating provisioning for your operating system, your networking and your container runtime, which is consistent across all the nodes you have. Regardless of the application running on it, your operating system, your networking on your container runtime should be the same. And that really gives you one first benefit is instead of dealing with inconsistencies and this snowflake configuration, by adopting containers, you ensure that this 90%, this 80% below the value line is consistent even though today it's a lot of the security work today. We do today trying to figure out whether our service will configure. On top of it, we put containers. So the container runtime is critical in security aspect and that's really what we're going to do. But also the application, the content of the application as well is very important. So let's dive into those patterns, those key points that we need to look at in container security. First, your operating system. In the past, we were deploying big operating system because we wanted them to be able to run anything. We didn't really know what application would be deployed on top of it. So you need to have so many different cases that the operating system is maximized and is pretty bulky. Once you move to containers, you want and you really want to focus in terms of minimizing the size of your containers. Why? Because from a security perspective, we see more and more what we call lay of the land attacks using what's already on the machine to be able to leverage and do attacks. So by reducing the size of your containers, from a developer perspective, you make it faster to deploy from a security perspective. If you reduce the toolset, an adversary would be able to use. Of course, you deploy applications and you deploy versus automatically. So you want that to be hardened as well. For the technical folks here, you definitely want to look at the Linux security modules that are important for security. Our mark can really help you maximize the security and reduce the ability to evade containers. Name space separation is very important, but you still need to focus on making sure that you have a different more. But really the core of the benefit we have in cloud native is the principle of immutability. Everything's automated and you're not changing it manually. You reduce the risk of having independent configuration changes. You remove the fact that people connect on the server and do changes there. Everything's automated, everything is consistent. Everything, all your operating system should be the same. And I'd really reduce a lot of the security overheads we have today, because if you remove security administrators connecting to the systems, you reduce previous access challenges inside of threats. That's really an aspect that is important as well. When you do security incident investigations, if everything's immutable, everything is the same if you take the investigation and the fact of finding the mistakes. So it's really the core aspects of cloud native immutable. If you do changes manually, this is the bad pattern. Great. Sorry, I don't know how to click anymore. The second aspect of it is networking. And very often what we see in terms of adapting containers is because networking is really hard and you're going to have a lot of workloads and everything, it's very common to just open a flat network where all your servers and all your nodes are on this open flat network. While it's easy and good for efficiency and getting things done from security perspective, that's really not the best approach, because that means you're really increasing your BlackStrength. If any of your containers is compromised, you have a risk of lateral movement that is increased. If you think of the cloud, really what we enable is software defined network attribute-based filtering. So really, if you do and want to embrace large-scale containers, platform is very important to understand that you want micro-segmentation. You want to really segment appropriately, but you don't want to deal with IPs because IPs are changing every day. So really, networking, remove flat networks, think of the software defined network as a way to do finer-grained filtering that is adapted to your business. The next level up is really the container runtime. And again, here we see a lot of mistakes and felt in a piece of really be cautious about it. Unfortunately, still today, we see reports of Kubernetes platforms that are exposed over the Internet, whereas the APIs are exposed over the Internet, or even worse, a node conjugating that means anyone can do everything. Once everything is open, is software defined. Once everything is driven by APIs, you really want to make sure your API endpoints are secure. This is really the core and the center point of all your data center. This is not secure, and nothing is secure in your environment. And another big mistake we see is to run privileged containers. One of the core benefits of linked containers is to create namespace operations to make sure that everything that runs in the container is actually not privileged outside or doesn't have access to modify your host. And that's really one of the things that is important in deploying or syncing your container strategy is to make sure that you run unprivileged containers so that even if your root is in a container, you have no one or no more user for the rest of the host. So really, again, limits the amount of damage that malicious user or an attacker would be able to do is something happens here. So really, these are the two core very, very important bed flags that should be mindful is making sure that everything is protected. Your APIs are protected and your privilege runs contained. But we still have something that goes inside the container and that's really the image. And that's where really we see the difference. The difference is between container as a service or container platform and application platform is where your image comes from. Once you deploy container platform like Kubernetes, you really still build the content of your image. And that's really where it's extremely important to protect your pipeline, your registry, where all the images are stored. Again, the center point and the crown jewel of your platform. If someone has access so easily to break into your pipeline and modify your things, then you're losing the benefit of the immutability of your environment because everyone can change. Again, saying you may put all the security tools in your pipeline to do what you just can. If someone can compromise your registries and everything on the platform will potentially be compromised. So these are two very important red flag, protect your pipeline, protect your registry. And because you're building your developers will be building the content of the image, putting your management, of course, as part of the pipeline is extremely important. You don't want to ship vulnerable code. Unfortunately, public registries of image are known for having malware or a lot of analogies. So this is a very important aspect of them. If you use an application platform, typically you would benefit from pre-built image by trusting resources, by trusting the sources. In VMware, there would be application services, there would be the application catalog. And do use them. That means someone else does a job for you of looking for vulnerabilities, providing you the latest image. So do use these benefits. But that also means that helps you keep everything updated. Just deploy regularly to make sure that you have the latest patch because still today unpatched software is one of the first source of compromise. So there's three gaps. That means when you build a platform in communities, the platform for building a platform you want to have an image, you want to have your trust network and micro-segmented. You need to make sure that all these encryption is done, there are lots of them. And this is one of the big benefit of going through a platform is you build it once you do the hardware points of all your compliance and all your security controls and every application that you ship onto it will benefit from it. And so what is the benefit you go through? You go, you provision fast, secured by design and environment. And one of the key principles of cloud native is to make sure that you have parity between development and environment production. So do provision development environments that are the same as production so that you don't have these challenges of application that run and works in depth and do not work in production because we introduce security. This is extremely important in making sure that you increase the flow from developers to the environment, give them environments that they know will work as well in production. That helps you reduce patch cycle, that helps you increase the consistency across the nodes to increase the durability of your infrastructure. Immutability, reducing insider threats. And so the declarative network also helps you enforce business logic as an important security policy instead of hog cutting firewalls that really didn't really have any relationship with business logic anymore. So very quickly, if we look at the security aspects, we would like to look at it from a kill chain. You can't do anything about an attack, but once your container is compromised, the first thing you need to do is to reduce persistence. It's done through the hardened operating system and on privileged containers. You need to reduce privileged escalations. That's done by removing credentials and all those secrets from your code. That's very important. Rotate them regularly. It's done by reducing lateral movement. And most containers platform today will provide you a service mesh that will provide you container to container networking in this diagram. That's what Envoy does, making sure that all communications are filtered, authenticated, and that you declare every communication that is allowed across my services. So once you do that, you really get a lot of benefits. But there's three very important things that you benefit as well. The ability to patch with a downtime once your application is distributed and we'll go a little bit more into it later. The ability to destroy rebuild because everything is based on code. So from an incident's response perspective, that's the benefit, but also from making sure you don't have malware, that's another benefit. And removing the secrets from your code and rotating regularly also actually reduce the sources of data breach. I believe stolen secrets is in the top three of the sources of breach today. And so being able to do that is extremely important. So we've talked about containers. Let's take a little step back and think about how cloud native applications and cloud native practices have security. So anyone who's familiar with cloud native, we know that we typically look at those applications around 12 factors principles. If you're not familiar with them, just with them it's very important. If you want to summarize them very quickly, that means that really about focusing on applications that are disposable, stateless, microservices driven, that are container based to be able to be portable and API driven. There's a little bit more to it, but that's really the core of the gist of it. And so if you look at those three factors and you try to extract what's the value for security, I usually look at a framework that I call the idea approach. And it's really about being immutable. No change once you push to prediction. Don't change. Just rebuild. Distribute it. Every application should have several nodes so that you can have full terrain, but that also allows you to do patching. FMRL, we used to in the past have those servers as those applications that we want to have up and running for so long or that are inherently up and running for so long because they're so tightly coupled that we can't patch that we can't turn them off without having a long negotiation with the business. Once you deploy and you design applications that are cloud native, you want them to be effective. You want them to be able to be destroyed at every point of time, at least a node. One of the instances without impact to your business, that's what allows you to deploy application seamlessly to your business but also allows you to patch and to destroy and rebuild. And the other aspects and very important aspect is to make sure that everything is authenticated. In most organizations today, in most of our applications, we expect to have users that we know connecting to those applications. And so whether it's a network infrastructure, your application, everything should be authenticated. Most of the applications should be authenticated. And if you think about it, the benefits we have is we've done a lot of progress in authentication system through adaptive security. So we have a pretty good idea today in applications that our user is pretty our users. Step of authentication to factors really helps making sure that this is the right user. So if you make sure that your application is authenticated, even if you have similarities, you reduce criticality of it by just making sure that you know who is involved. Of course, there is always some, this is a little bit simplified, fine, but by really authenticated, all you are in point you massively improve your security because your cross-site grid is your cross-site request for Azure AD. If you know who they are, it's less likely that you have a cyber criminal behind if it's your customer behind. So really look at those four principles because they've really changed the way we do security. Immutable AD really increases constancy and allows you to have to be auditable. The distribution allows you to filter on some of the other passion. Ephraim workloads allows you to ensure that the code in production is actually what's in your repository. And that really helps again on the auditability, but that also allows it helps you in confidence that if tomorrow something happens, you can rebuild at any time. Your authentication really improve traceability, but also improve and reduce your risk by enforcing zero trust. And it really maps down those principles to the key aspects of data breach today. Certain credentials, backdoors, and unpacked vulnerabilities. If you're immutable and you know that no one can deploy anything and you can destroy it to make sure you push clean code and clean application at any point of time, your backdoors are gone. If you're able to rotate your credentials, your stolen credentials are gone. Really we see these benefits everywhere. So we look at the new cyber hygiene today around the three cars and it's a simple way of remembering by improving the ability to repair, to find your vulnerabilities and fix them faster by having distributed system and immutable system that can be, that can be by zero downtime, really improve security. By having code-driven applications that are distributed, you can repave, which means rebuilding regularly to make sure that what runs in production is what you want and not something has been compromised. If you rotate your credentials again, all those bridges that we see, that we see where people found credentials, big users of being your APIs, being your infrastructure, even if they leak out, if you rotate regularly, you reduce the risk of this configuration as well. So if you want to combine, once you combine these, we really see the benefits. These are important principles, but we only believe in them because we see them working. And so even though our native is not designed particularly for security, it's designed for developer productivity, for developing better apps and releasing faster and we see improvements in those factors. It's the same fabric that enables developers to deploy application fast that enables those platforms to scale or to reduce the overheads and the infrastructure actually allows our customers to patch. It actually allows you to make sure that once you build a platform that is compliant, every application they push into it is deployed constantly and it's compliant. It really reduces overheads and allows your security professionals to actually focus on the matters, on finding those vulnerabilities, on improving their work with application security to find the parameters that you to act in terms of advanced monitoring cases and response to risk. What we also see is large organizations who are destroying and rebuilding regularly their infrastructure for business continuity on one hand, but also to make sure that even if they are compromised, the attack window, the time that the attacker has to find another vulnerability and move out of the platform, move to the objective is reduced. Some of our customers are doing this weekly without downtime to their business and moving towards being able to do that daily as well, publicly, because this is so much benefits into it. Once our version is code and once we've practiced it, it's very important that the benefits are absolutely massive in creating a platform where everyone is confident that even if something happens, we can recover. And really at the bottom of security, even if we look at all those advanced threats and advanced persistent attacks from the nation states, the core is mostly, most of the case, missing patches. So your ability to patch faster is tremendous. We see improvements at our 9x between the existing environment where security struggles to get patched up high, where you need to negotiate patching windows with a business to bring down an application where you have critical patches. And it's really critical because this year we see vulnerabilities that are exploited immediately by attackers within days. Even within the third day, the vulnerabilities disclose. So your ability to patch very fast when it matters is extremely important in improving the security. And what we really see is improvement in those security outcomes. Your ability to patch, your ability to recover, to rebuild regularly, your test coverage is a developer practice that actually reduce as well the number of work that are being produced. Your ability to reduce and rotate regularly all your secrets in your platform really reduce your risk. And if one day is one of those secrets is leaking, you have, it could be used for that. So this is it. If I want to summarize all of it, I have three goals for you. Think about this idea principle whenever you develop another application. Really, is my platform immutable? Do I have people connecting to production? Is it distributed? Can I patch it regularly? Do I destroy it regularly? A very important principle for your application and particularly for your perimeter. If all your perimeter, everything facing users or internet are destroyed and rebuild regularly, you've massively improved the security of your organization. Even improved the security of the backend system legacy backend systems you had. Resink your controls. Once you have a thermal workload, a lot of things in security changes. Incident response is changing massively. So when you do your audits and your malware prevention is very different as well. So rethink all your controls and making sure that you leverage the fact that you can destroy regularly. And also very importantly, optimize your faster production. Optimize the pipeline to make sure that not only your developers can push code very fast. And it's extremely important. But security can also change fast. And what we see is by adopting cognitive architecture, we see those winning. Developers being able to develop any faster, security being able to react faster. And this is what frictionless security is about. Removing the other heads so that everyone can focus on what matters and finding those advanced cases and working together. So that's it. Again, I wish I was with you and we could have a more interactive discussion together. But reach out to me, please. I'd be happy to deep dive this with you to explore. Hope we can help you. Hope Clarity can help you improving your security. And all everything software defined can help you improve your security. And changing the way you look at it. And do it, please. It was a pleasure sharing with you. And I hope that you'll reach out to me and we can have these interactive discussions that we would have nobody have. And thank you very much. Have a good day.