Welcome. Can I run to the, to the session? So our workshop about cloud native security as part of the cybersecurity leadership summit from last week, which we plan to do on Monday, last week, but there were some technical issues with the platform. So we decided to find a new date, which is today and use Microsoft teams as the platform to share content with you. My name is Jan scaring, I'm technical sales manager from Palo Alto networks today I'm without my partner and crime, Stephan Cher, who's who's out due to illness.
So yeah, I have to, I, I have to cover several things sometimes in parallel, especially later on when we are in, in the game or in the path where you will have the opportunity to have some hands on. I hope I can have everything under control in terms of looking at the chat, answering your questions, but also managing the gaming engine, but I will give my best to provide you great user experience.
So I introduced shortly myself, just a few sentences around power as a networks workshop and the, and some additional expanding S of myself. I joined Palo Alto networks around one year ago.
And before this, I was almost three years at AWS. So the biggest cloud service provider have for out and the market. And then my part was to, to yeah, to guide software companies on their digital journey, by transforming from perpetual license model to cloud native software as a service applications. And then when I was at AWS, I was always fascinated about the mantra, which was inside AWS, especially CTO security is drop zero, and this is actually what, what led me net. Cause I really love what I, what I have seen in terms of technology acquisitions. And here we are.
So today we will talk about cloud native security and what companies can do in terms of implementing dev SecOps pattern into the organizations and how technology will helps them to achieve their goals.
This workshop contains of basically three path, the first part, and I will, we tried to hold it last week, but there were a lot of guys having problems with the connectivity. And so not all of you have heard what I told you there. So the first part is, is based on theory and some slides.
This is important to understand, especially why cloud native security is or works in a different way than you guys. You used to do in the past with his legacy security, it patterns. I call it this way. The second part is then going into our technology into the degree, giving you some advice, showing you how you can handle, handle this and how you can manage and operate in, in our technology. And then the last and probably the most fun giving part is the third part.
Actually, as part of this workshop, we have set, set up can really do hands on this game is based on kind of yeah.
Or it's based on the Facebook engine for captures the flex. So actually virtual captures the flag where you can solve challenges around cloud native security. So this is what it's all about. As an intro I see now more and more folks have joined our room. So this is great.
Happy to, to be a host today. And I will now start first part. So the presentation of theory on what is cloud security and why it's important to think in a different way, if you want your native architecture and applications, is there any questions of course, feel free to, to write them in the chat.
As said, I, today I'm alone without my partner of crime, I will look into it there not always possible. It's not always possible to in time. I definitely have a look at the chats.
Okay. Let's start on with the intro, the things some, some guys of you have heard last week already.
So that's a reason why, why companies use cloud native technology and what has changed and also why the challenges out there and the reason for, for using cloud and cloud native technology is basically that those technologies help customers to modernize a software stack modernize on the one hand, it could be a use case, but also using those technology to develop new applications. So nowadays, if you are in the luxury situation, we need to have a project where you can companies are doing this. Yeah. Because it's it's business, it's a value add on their business
Model. Yeah.
Then you wouldn't start with doing things you have done in the past, like using the waterfall modeling or you won't, you won't code a big monolith. Yeah. Which is very difficult and also expensive to maintain. So nowadays you would start right away with using microservices, using new patterns, like DevOps in terms of all the old stuff of batch releases. Yeah.
And that, and therefore you use native technology and one thing, which is very important to understand, because if you, if you don't code as you, as companies coded 20 or 30 years ago, yeah. Then it use all those fancy new technology. Then there's one pattern, which is super important to understand. And which brings also a lot of complexity into it course, you have all those beautiful microservices, they talk to each other and there are a lot of good things happening in the backend, which the users don't see, for example, take a look at Amazon com.
Yeah. It's a big web application.
And what you don't see in, in the backend is that's this web application cause consists of over 20,000 microservices and there's an update each three millisecond seconds. Yeah. So you don't see this, this is good from a user perspective, but you can imagine there are a lot of challenges because it's super agile. It changes a lot. Yeah. And if you want now to be efficient by using those technologies, then you have to operate, you have to automate. So in operations, everything has to be automated.
Also the, the underlying infrastructure provisioning. And this is what you can see here as the last pattern. So custom to come operating model. The answer to, to this is in general, using infrastructure is code. So basically describing language to provision resources. If you don't use infrastructure as code and your application gets more and more complex, basically you are, you are almost lost.
And now this is super important to understand, because this is, is a common operating model. Yeah. And there comes some risks visit. And this is what's pointed out now on the next slide.
And obviously there are challenges from a security perspective when you have an agile environment and basically you give a lot of responsibility to your developers and using DevOps and so on and so on. And at Palo Alto networks, we have our own research unit. And this research unit is not just the research units, which provides colorful charts. Of course they can do also. But they look really at, at what's happening in the market. And for example, what they did, what they did was when they released in February this year, they released a cloud ring report.
The result of what they've done was shown in the context of infrastructure code templates, because I looked at public available, repo like GitHub and so on.
And I looked at almost 600,000 infrastructure code template. And the result you can see on the left 42% of those templates, which are used for the cloud operating model shown in slide before are insecure by the four. And now imagine use a template for what of course pro replicating. Yeah.
You use this template and then use it again and again, and other and other divisions in your, in your company, we use it mainly modify it and then reuse it and so on. And if 42% are insecure by default and you use this and you use this template, then the risk of obviously gets higher and higher.
When, when this infrastructures code have made it into your organization, or if you created new your own infrastructures code and it's insecure by the default. Yeah. Yeah. You go. And then also super component to understand because cloud, because cloud native technologies is not only using the services of the cloud service providers, it's also technology technologies you can partly use for on hybrid deployment and for example, container.
And what, what we can see here in the second pillar is that our research unit for the two has found outset over 50% of exposed Docker containers have insecure defaults. And sometimes those are, those are hygiene techs. Like for example, it's against the Docker CS benchmark to create, to create an image as a root user. So you should create it as a non root user. Yeah. And the dock here has benchmark test, but the point is the default setting is creating an purchase root user. And so you have actively have to change it.
So basically not a big thing, but if you lack kind of technology, which helps you foster those settings, then there's a risk. And obviously you can see the risk is with over 50% of the containers out there. And then to, to other to other interesting numbers, host vulnerabilities. If we look at vulnerabilities in general at legacy on OnPrem host, for example, numbers are between seven and 9%. Something like this, if it was the general market data and for host for, for cloud host, you see release at 24%, so much higher this, and by the way, this is not the fault of the cloud provider. Yeah.
It's a configuration thing and how you handle abilities. But as you can see, agility rings also a lot of speed. And then companies sometimes, which is, which is here as a proof of evidence. Yeah. Lack.
Yeah.
Like the, the tools of the operating models to, to, to get better in those sections. And last but not least you can see for the 3% of cloud database are not encrypted. This is a thing say, yeah, it doesn't have to be this way, but obviously it's reality.
Now, one thing a lot of you guys have seen maybe a thousand times, maybe not a thousand times, but the point is, whenever you look at, when you, whenever you talk to cloud service providers and they educate them about the beautiful platform that they can use here, here, at some point you will, you will come to some kind of abstraction of this, of what is shown here. And what is shown here is the so-called shared responsibility model. And you really need to understand this to efficiently cover cloud native security. Cause basically what it tells you here.
And you can see below the line and what the responsibility of the cloud providers, the cloud providers responsible for securing their data centers and their services for users. And you can really trust their super strong there. So I would take any bets that it's more difficult to get into, into cloud service provider, data centers and to any other enterprise data center. Yeah. They're super good in, in it.
And they, they know how to secure to protect. And of course they, it's also their responsibility to provide you with the services you want to use. But then the point is, and this is why it's called the shared responsibility model. The point is, it's always your responsibility, how you use those services and independent, if those are infrastructure or platform as a services or software as a services, it's your responsibility, how you configure and how you use those services.
Yeah.
And you can see there's a shift from the responsibility if you use between infrastructure and software as a services, of course. Yeah. But at least all about the data and your responsibility to take on. But now this is an important point. Even if you have understood systems, that is your responsibility. One thing that goes even far beyond is something which, which a customer shared with us and which is super simple, but super good. Right.
I want to, I want to share with you is the point that if you draw down all elements yeah. You will land at a classic race chart. Yeah. So race chart.
So something probably all of, you know, yeah. And if you draw down this race chart for your cloud usage, then you will end at something like this and don't have to read now every sentence and regards, which with there's one point, which is you can see there's only one R at the cloud provider, which is basically telling you how Porwal infrastructure.
Of course, it's their infrastructure. It's their responsibility because that's the security of the cloud, not the security in the cloud. So one R only there. And the second point I really want you to, to, to, to get as a takeout is the accountability is every time with you, sir, there's no way to outsource accountability because if something happens with your application or whatever you are doing in the cloud, it's your accountability.
So really important to understand there's also tructure because between responsibility and accountability, and if you, and if you provide a new application, a new business model, maybe on top of your legacy business model, or maybe as just a pure, just as a pure business model, because you are startup or what, whatever you have your application.
Yeah. And there's, there are certain things your users or your customers will forgive you. Yeah.
Maybe, maybe the latency is, is not that good. Maybe you have a downtime here and there, but there's one thing they won't forgive you if, if something happens with their data and that's important to really understand security is drop zero and especially accountability is your drop for those things you, you do based on, on the, on the stuff you do inside the cloud or with cloud native technology.
Now having talked a lot about the things that are happening outside, where there are risks and also why it's so super important to understand what you, what you need to take care of is now having talked a lot about this and coming to the next thing, because this whole workshop was also intended, intended to give some guidance on what you can do on really embracing a dev SecOps yeah.
Mentality, and also implementing a dev SecOps.
Now, when talking about DevOps, normally it should be the, yeah, let's say the core definition of DevOps is ability run it obviously, but there's also a reason as you have seen with the, with numbers and, and risks out there that security is not always already a major part yeah. Of DevOps. And this is, and this is because obviously the technology is new and things like DevOps in the applications, it's, it's a natural learning process.
But the point is, if you are in, in this DevOps mode and you are operating in it and you have, and you have the responsibility and you doing a lot of things and you want to release, and you're doing your sprints. And so on, sometimes you might forget about the security part or not even aware. And our point is, now, if you look only at the end, when you release this application or some features, and you look at the end, is my application secure, then you might already be lost because a lot of alerts will pop up.
And it's so going back from there, it's first of all, expensive, and you might get also alert fatigue, that's called this way. And now really, if you want to embrace dev SecOps, that technology can help you. This is what you can see here. So our technology at power Alto networks, which might help here is called prima cloud. So you will see later on in the presentation, you will also have hands on for SMA cloud and prima cloud from a technology perspective, can help you implementing security guards, guard rates as early in the lifecycle as possible. And this is what you can see here.
So you have, every company has, has in the software development life cycle, they have the face, have the deploy face. They have the run face. And now imagine if you could do already, or if you can implement already a lot of security guards, right.
Super early in the life cycle. So a developer is in his IDE, whether it's intelligent, whether it's code or whatever IDE he's using. And he makes he can makes this simple things like scanning his infrastructure code template or planning his container.
He, he want to push into the, into the, the ANSYS helps to avoid sometimes simple things like the DACA image I I had before. Yeah. But also sometimes things which was known to them. So an insecure setting for the infrastructure code template, or they have created the image or whatever. And you can simply prevents us by using technology. And it's a hub that's, this should be super clear, should be a help for the developer because the developer wants to build a secure application. Yeah. And it helps them.
So this technology is not really like in the old days, setting security door and telling the developer, Hey, you only allowed to go through the store by, by having this, this all check marks.
It's really easy for the developer because he he's, he operates in his tool. He has ever used.
And okay, there's a simple check. Oh, easy to change and so on. So this is really about dev SecOps. It's a collaboration between several departments. And then if you go into the deploy phase, of course you can scan, you can registries, you can use your C I C D tools you have in place like Jenkins through also let builds fail. This is your com companies strategy to be very strict on server things, but also to inform, okay, this build pipeline hasn't failed, but there are vulnerability in, but those are not critical.
So it's, it's up to companies to decide this, but technology really helps to automate here and to provide this visibility to it as early as possible. And then obviously last part also important, super important.
But the last part is then one phase. So really what happens in, in your deployed stack now the approach prima cloud takes from, from a technology and from a platform perspective is that if you look at cloud native technology, and if you look at several risks, which come that you can choose a lot of tools out in the market, and many tools are point to point solutions.
So one, one tool is it's helping you to, to solve one issue and you can use this tool, then you can use other tools and so on and so on. And this is normally what developers basically did in the past.
Our point, our vision is and where we say, okay, but the pictures broader comes to a platform approach on the one hand, this technology should have for sure developers, as I explained before, building secure applications. But there's also a view from higher sec ops perspective because there others departments at customers, maybe customers have have the so yeah.
And the so really needs to runtime and they want platform to have the holistic view as there are other yeah.
Responsibilities inside companies like, like the C who really wants let's, let's say one click reporting, am I compliant or whatever the question is. And in that regard, and this is where the platform play comes into platform, which comes into play. And what our vision is, what we provide is customer cloud is not only a point point solution for, for this. And for that, it's about giving, giving customers a central platform to operate it, but as open as it can be, it will come back later with, and as, and to integrate with existing existing solutions.
And what you can see here are basically form modules. Every model is important in the context of cloud security. And then the left side, you can see at least takes those acronyms with you because they help you to navigate.
Also later on in, in, in the hands on workshop, the first two models are super important because those are the things we do in the HandsOn. Yeah. But I will explain are all format.
So cloud security, post management, those security posture management, and what, what you can see on, on RA is basically a continuous configuration and compliance monitoring for all your cloud resources. Yeah. Are those cloud resources you provision and it's your responsibility, how you, how you configure them, are they secure as a compliant? Yeah. And there are, and there are patterns to, to, and this is what our technology does. And I will show you later on how, how, how would such things, so this is all about the visibility, continuous compliance, configuration monitoring.
So take CS, cloud security, posture management, the acronym is a kind of orientation for certain use cases. And then also the second one.
So the acronym very important to navigate later on is the CWP, the cloud worker protection. Cause if you had now all visibility of your cloud resources, what's, what's happening inside your AWS environment, in your GCP environment or what or whatever. Then at some point, the question is okay, by workloads, they run on a, on a certain abstraction of compute power.
And in, by using cloud native stack, this definition of compute power can be different. Yeah. Of course we have old world by using posts basically. Yeah.
So the, I would say the most, yeah. The most easy part and, and probably not the way to use cloud in efficient mode, but of course the use cases for, so basically using workshop machine. So that whole security is one abstraction of it. Yeah. The abstraction might be, and is basically the standard nowadays for, for cloud native department are container yeah.
Work in a different way. They run also on host can version machines or bare metal. Yeah.
But containers work in a different way and yeah, as set, basically the standard nowadays, if you, if you can design new architecture, so this is one attraction and the other attraction is then is serverless. Nowadays. Also many companies start with using serverless and that's so is I would call the paradise for, for developer.
Cause he, he doesn't have to take care of, of anything. He just writes his code, throws it over the fence. And the server architecture provider just ensures that this code is processed. Yeah. So you can see there's, there are certain abstractions of this compute power, whichever you use. But the point is you also have to protect it and you have to secure, and this is what our cloud worker protection module does. And now again, I recap, this takes a second.
So the C WP, or sometimes it's CWPP platform, second module, you will have a hands on later on as part of this whole platform approach and then as there's to, to other models. But those are basically not part of, of this workshop. When you talk about cloud network security, it's not, not only about looking at the VPC flow logs and not gate based and so on. There's also in relatively new pattern. Yeah. So you can also with also with microservices, you can, you, you can use identity based micro segmentation. And this is what is called network security module is about.
So basically giving each and every microservice, you're using a unique identity and defined based on this identity, what this micro microservice is allowed to do, and then nothing else this microservice can do. So this goes into the part of zero trust approach into in cloud native architecture, just as a short explanation and then force module also super important from holistic view cloud native security is the IM module or how we call it the cloud infrastructure, entitlement management.
Because one thing we have seen in the, especially in the last years is there's the IM sec that the IM security will be against the first line of defense in your cloud native architecture. Cause so now some years back and really I can, this is what I also experienced in, in my time when I was at AWS. So some years back at, so working in the cloud was relatively easy, had one cloud account. And in this cloud account, yeah, of course you might have used AMR IM rule or maybe not many users really against some, some years ago where we using their root account. Yeah. For putting everything into it.
Yeah. And then at some, sometime they maybe started to give some am or to open some am modules and give others access limited access there.
So, but the world was relatively easy. Yeah. Secure your, your one cloud account or your one IM you're supposed to work with.
Yeah. This was the past. If you look nowadays at how cloud native, how cloud security works and what you can do in the cloud and especially big organizations using the cloud, then you have a cloud organization. So you have a root account and you have several subsets of other accounts and you give permissions to those accounts and you also have those IM modules and, and IM role can have access to this, to the one cloud account and then to, to another cloud account.
And then you have policies and then you have roles and it's a super complex construct. And if you really want to secure everything and follow also, here's a kind of version of Ze trust approach. Basically you should follow these privilege commissions set up, but it's so difficult to achieve this and complex environment and the environment as a get complex. And this is what this module does.
So really it's, it's an effective permission calculation. And then giving you advice to drop all the right, which are not needed.
And it's really important to census because if we look at the big reaches with chap and one of the most famous reaches was at capital one. So a big FSI customer in us and capital one was, was the, the was one of the most used customer references for AWS because they had the big cloud transformation as the C was going out there say telling everyone, Hey, the cloud is more secure in our own data centers. And he was right from the understanding of security of the cloud.
Yeah, he was right the same. And his organization was also major and using cloud. So he did a lot of capital, did a lot of things, right? So in terms of their responsibility when configuration resource and so on, but there was one point where one user has massively over permissions and tech us get into this account account and some then inside out threading in terms of how, how, how you get into, into architecture and went from there.
And then this was space on the tech that there was an over permission in terms of the IM security setting.
So nothing you want to do, or, and obviously nothing you want to have as a company over, over permissions in your cloud. So this is where the is so super important. And nowadays if I turn around, so I am security has to be the first line of defense in your cloud environment. Okay. Now leaving this platform from audience, I hope it's, it's clear what you can, what you can accomplish with this technology. Just super short recap about how parallels networks came there.
Most of, most of you might know, parallel the networks from our firewall business. And that's good. We are super proud of our firewall business and being the leaders, the next generation firewall, but cloud native security, U probably seeing from my presentation now is different.
And what com and what companies do then is they look at the coolest and most capable tech startups in the market, and they acquire them. And in case of power networks, they integrate them. And this is also important to understand. So we start with red and then IO acquisition back in 2018.
So those two were integrated begin of 2019 and is basically CSP module and then followed by other acquisition in terms of the serverless and container security with pure second, Swisslog also integrated by end of 2019 into the other module. And Appal is I think before with the identity based micro segmentation, a company, which we required last year and will be integrated by endo this year.
The point is from our, from our view again, is to understand that we are putting a lot of effort into the integration because we don't want customers to repeat the sense of the past, which I explained in context of, of selecting point to point products here and there for every use case, because you can't, you can't manage all those security tools then afterwards.
So it's all integrated, and this is how, how we get there.
So Twistlock Welock was the market leaders for CSP and for security, and also important to know that we kept all the IP and also all the effort which we, which those companies did before in regards to the CNCF or the cloud native compute foundation, for example, our was the C of two S which, who still CTO at Palo Alto networks. He was the lead author of, of the missed eight, 800 minus 190. So basically the cloud, the container security baseline for everything, which, which happens. So we also a lot, the CNCF, we are a commercial provider.
Now I talked, I that you, through the possibility of integrating into your tool set here, you can see a lovely summary and please be aware that those are just example logos. You can see here in terms of the dev tool integration. So our platform has to be open ended is open. So basically you can use every tool, even if we don't have provide a plugin for your DevOps tools, but you, you always have the possibility to make infrastructures code scanning via our rest APA API, or you can do container image scanning by using one component of, of our platform, regardless of the tools you are using.
But you also have a very proper list of plugins you can use, like for example, Jenkins. So there's no need really to switch through the tools you in Jenkins develop, can the build fail or fail or path, depending on the security guard, you said for the compute supported compute platforms, as mentioned before, for us, it's, it doesn't matter which orchestrator or which, or which engineer you use.
So for example, if you have your dock installations, on-prem, you can secure them with our technology too.
Yeah, it's it doesn't matter for us. If you use managed, if you buy a commercial solution like Shaw or OpenShift to have additional services on top, we integrate with all of them. And even if you use the services, the cloud providers give you like AKs, EKS, ECS, GKE, whatever is out there, we support those. So everything is supported here for the big cloud provider resources themselves.
So for the configuration compliance monitoring, we have four big cloud writers, which are supported starting of course, with AWS GCP, but also Alibaba cloud, because we see a lot of German or companies, at least having a look at Alibaba cloud, because it's sometimes important for the export efforts yeah. To, to have also digital business models over there. And if you are, if you are in China, then obviously you there's this yeah.
To bypass Alibaba cloud might be a bit difficult, but anyway, so you can see there's a complete picture of the, of the integrations we support here.
And the technology I presented to you with SMA cloud that can be used as software as a service in this case, it's running also in the EU. So basically it's running in a Frankfort data center on AWS and GCP. So you can use this as software as a service. And this is what we will use later on in also for, for the demo and for the gaming engine. And if you really have an air gap environment for your containers, which are on-prem, there's also a version where you can use PERMA cloud container security as a self-managed license, if there's a need for, okay.
So this is just a summary slide and which should help you then after this, after this workshop, yeah.
To have an orientation about the use cases, what you can do now in cloud security, post management, this is thing for you, what you can do in there, but also for the cloud workload protection, just as explained. Yeah. Okay. What does container security now really mean? And you can look at the micro segmentation and so on. This is just a summary slide for you later on. I have talked a lot about it. So this is just for your handout purpose.
Now, how does it work? And this is important to understand, and this is by the way, this is also the answer, why the classic inline security doesn't work in the cloud. Yeah. So our point is at power networks, as I explained, many, many people know power networks from our firewall business. And we also have virtual extractions of all firewalls with all BM series and even CN series.
Yeah. But the point is on the cloud, you can, you can, you cannot, your should use our virtual firewalls and you can put it in front of BPC and put all the traffic there. So this is great. Yeah.
But the point of the cloud is you can only protect then therein. What is in there. If the next developer comes and spins up a new web server outside of this BPC outside of this firewall, oh, then it's not protected. So this is basically the reason why classic inline security doesn't work in the cloud.
And, and the point, and this is that's the point where you need cloud security, post management really have the visibility of what's happening in your cloud environment. And now the beauty of cloud on the other hand is everything which happens in the cloud is an API. This is an API code, as simple as this.
Yeah. This is the logic of how cloud works. Everything is an API icon. And what our technology does is, and this is really heavy, heavy, heavy lifting, but that's, this is the reason why there's technology out there to help customers understand it.
So our technology takes, those is able to read those APIs for the four cloud providers. And based on those, and based on, on, on, on the findings there, which are all the resource configurations, which are the user activities network flows, and also the host activity, which is happening there, we collect, we collect all this data.
Cause we, we are able to understand, and this is asset. This is already super heavy lifting. Yeah. For example, at AWS, we are reading now over 100 APIs, something like this. Yeah. And you can imagine understanding all this APIs is already heavy lifting, but then also a part of where really the technology powers in, as we collect them, we aggregate them and we normalize them because not every everyone is able to understand all the cryptic stuff happening in the cloud.
Yeah.
And this technology also should help people who are not 10 times certified cloud specialists should have also sec of teams. So teams and so on. So we normalize it and we provided in, in the form where normal people are able to lead it. And so we built and what we do there is we built all based on this data, we built an asset inventory. This asset inventory also contains a CMDB. So configuration manage database for all the cloud cloud resources, into the inclusive whole history of it. And based on this, you can also do all your out box compliance reporting with just two clicks and so on.
So a lot of functionalities which come, come out here. And of course this technologies is also builds, is built cloud native. Everything is an API from our perspective. So basically everything which you can find inside your cloud environment is just an API call to, to integrate it into other words. So for example, if you are using, if you're using a scene tool like Splunk, it's super easy to, to ingest the findings.
Or if you want to put this into a ticketing tool like service, this is how the cloud security post management module works to make, to recap it very short, simple, everything's an API. The second part is the cloud workload protection.
The cloud workload protection works a bit different. It has to work different because containers work differently than just providing an API. So obviously you also have the console or the, I would show show later to you.
Obviously you have this where all the policies are sort where you can visualize things and so on, but there are two other components which, which are important. The most important component is what you can see here. I hope everyone can see my mouse, but it's a small blue, blue icon here and the right mid of, of the slide. It's a so-called defender. So basically it's, it's an agent which for container security acts as a site container on the host to secure all the other containers and you need the site site container to protect them.
What, what this does is it looks at all the other containers. How, how are they configured?
How does they look like? So they build dependability, a complete manifest of this, of this, of the other containers. And so therefore we know how which packages are on there and, and this context, and we know which vulnerability apply to those containers. This is one thing this tender does. And the other thing is that this container is also reading the, is reading the behavior of this container. So which processes do you spawn? Yeah. To which microservices do you talk?
And based on those findings, we are able to provide a complete visibility of the east best traffic, which happens between normal thing between, between containers because containers represent microservices. Yeah. They talk a lot to each other. And so we collect all this data. And from there, we are able to build complete automatic one time model for customers to make it easy, really, to define the baseline from, from, from, from where they're operated.
And if there, if there are things happening, like, like starting process from a modified binary, we are, we are either we are able to, to even this or to, to block this such things. And this is important me to understand from an architecture perspective. So site container defender takes care of all the other containers, which run on the host. And then the third component I just quickly teased is on the top left it's the intelligence stream because this is our stream was out of over 30 distinct sweat Intel feed.
We use from the market to, to really provide customers with, with the latest and greatest the market in terms of vulnerability findings and to, to reduce also the alert, because by the fact that we use those over 30 distinct sources, we have super low force positive rate, and you always have the latest out of the market.
And this might be important in context of just you just trying you a simple example. So you have built your super clean container image it's running. It has no inability. So therefore is compliant. So therefore no risk.
One time is super and then a new renewability comes out in the market. So your, your container image out of the path suddenly has, has inability, which wasn't there before. And this is the reason why this intelligence stream is so super important because then, you know, ah, when is out, so this, this image, maybe there has to be some, some work or it's your decision to take the risk or whatever you do, but at least you always know status of your application there. Okay.
Sorry for the guys who already heard all of those things I sent to you now already last week, but it was important that we all, all the attendance chance to be on the same page when, when we get to the, to the demo and then followed by the hands on. But now we are, it's a stage where we can go into the demo and I will have a look at the chat if some questions pop up.
Oh, a lot of chat because there people joining and leaving. Just give me a minute, please.
Okay. As far as I could see no question. Okay.
I, I can't, I couldn't based on the chat, I couldn't figure out any important question. So then I will probably stop sharing and then launch my demo environment. And then we share, okay, now I share with you my demo environment. So you should basically see some dashboards. This is where it starts. So you can see it's soft as a server. So it's running in, in my browser. It's my enrollment. I'm set up as an admin in the hands on, you will see, or you will experience later on. You don't have all the permissions I have, but I can, I will use this to show you how to navigate.
And then for the challenge itself, it's basically your task really to play around and see what you can find out and so on. So what we do is PRMA cloud is, and I'm now in the CSP part, this is why it's important to understand those two acronyms.
So on the left side, every, every text you can see here are part of the CSP part except this one.
So the, which you can see the compute, this is module for cloud workload protection, just a hint for later on everything, every question which comes up with in regards to container security or serverless security, you can find under compute. Yeah. The rest of the questions are relating to cloud service resources. And this is under the CSP module. So everything exact, the compute tab, I will start from top down this dashboarding.
Of course, as I, before we have all this data, we collected them. We aggregated them, we normalized it. And then we are able to provide some dashboards for customers to make it easy, to focus on to orientate. And for example, one thing I really love is this dashboard, top internet connected resources. Yeah.
Because for some things you can argue, but for other things, obviously not. So web source probably is used to talk to, to the, so nothing, nothing special here.
But if, and for even, you can make a case for, for, for MongoDB directly to talk to the internet. If you have a new internet of things, application and, and internet provided the MongoDB to store to use it as a key value store, just to address data, there might be a case for it. Not sure if it's a good idea, but it's up to you to find out and decide. But if there's a sequel server talking directly to the internet, or you should, or you might look into it, and this is what you can do, then you can drill down here when I click click on it and this up a new window. Yeah.
So dashboarding helps people really to, to focus, to orientate insights, this complex environment.
And really, again, I love this dashboard and you can also see, see some hints for what traffic is not included, obviously everything, which, which is related to a not gateway gateway or has not listed here because those are not really resources, which, which chose workloads or data. So this is everything you can find here on the dashboard now is the next step. And this is a tab, which I love really the most, as simple as it is. Yeah. It's the asset inventory. And why do I love this?
The one use case I pointed out before is a part of visibility or the lack of visibility. And there's also in security, a pattern you can just called. You can only protect what you can see and really having an asset inventory is a great value add for a lot of customers. Yeah. Because they simple simply don't know what they have in the cloud environment.
And what we built up here is the complete asset inventory for it's a stage 3008 virtual assets. Yeah. And you can already see here, there's some color coding the screen.
Obviously we, the color coding for everything is fine, according to the policies, but also some, some things like red, okay. There are resources out there which also cause a lot and might not be configured in a way you want to be. And then going from there, there are also some, some other trends like you can see the acid trend and you can see here how agile cloud environment can be. And normally for that applications, normally you see something like this up and down and so on, but any houses, there's the average of our demo environment.
And then you can see also to make it really easy for you to navigate it's by classification. You can see, you can do it by cloud type.
You can do it by account name or by by region. Yeah. You can play a bit with it.
Now, having this visibility is the first step for, for many things you can do for the, for the challenge later on, please be aware that you have here filter on the left side and there will be questions and challenges that might help to use filters, filter to really get to the results which we ask for. And if filter is not on here, you can use this at filters. And then for example, okay, what might help me in terms of, of the question. And then if the answer is resource type, because you really want to filter for a certain resource, you can put it in.
And then the filter appears here on the left side, some of the most easy filters in terms of asset inventory, obviously as a cloud type filter, but also for policies, I will show you later on their interesting other filters.
And now if I, for example, click on AWS, then the whole, the, the filter only for AWS resources. And then you can see obviously that we have less assets because GCP and Azure environment are not show here anymore. And you can see also all the services which are in this environment. And by the way, one super important thing to understand this.
You can imagine those 2000, almost 2,500 assets are not all virtual machines or something like this. This is important to understand how, how complex cloud can be.
Look, if I go now into those, into this resource details. Yeah. For example, I take now Amazon EC two. Yeah. So one of the most common used resources in AWS because EC two is as a machines inside AWS. Yeah. And you can see, okay, for C two, I only have 2, 281 unique assets, but even there, if this demo environment we provide to the, we used to show our technology.
If we would have 280 virtual machines running here, just for demo purpose. Yeah.
Our, it would be much too expensive. You can imagine. But what I want to, what to show you is that even for the classification of EC two, there are a lot of other assets be beyond it. Yeah. Because EC two, in terms of a virtual machine, you can see, we only have 28 assets into it. The other assets are about a, about key, passive about network interfaces, all important things that you have in the cloud, but which make it complex.
And if you have really to check all of the assets in terms of configuration in the cloud, you can see for a very small demo environment having three, almost 3000 assets. Yeah. It's a lot. Now what I I have done is I clicked on the EC two instances only here and just, just for demo purpose now.
And let's select something like corporate EV server. Yeah. You can see also what our technology does makes now the drill down to the resource itself. And now something super powerful happens for our customers based on this resource. So Ely be about whatever is in our environment. Yeah.
It's what we built here is we show the complete history of this resource. So once this resource was discovered in February, this resource look like this. So we store adjacent config. We store the configuration of this resource adjacent. So it's also searchable and also important to understand for automat security, if you have to look at certain things, yeah, we have this, we have this store, but we also store each and every update in, in terms of configuration.
So for example, if you can, if you follow now and look at a change which happened in July, 2019, you can see super easy to understand for people red data green is edit.
And we also have here then the resources, how it looked at this day. So you can see a complete CMDB out of the history which we provide. I will close. Now those two attempts, which opened, because this was just a drill down for, for demo purpose to show you what you can do with this technology in terms of asset inventory.
And also in terms of discovery, now I will skip investigate, but I will come back later to investigate, to demo you, policies and policies might be a tap you meet during the, during the game. And, and for policies, we, we as prima cloud provide customer customers with over 600 out of the box policies. So policies, which basically describe how resources should, should, or could look like. So we get customers get 600 out of the box policies, but customers are also able to define their own policies.
Yeah. So here also, again, it's open, our platform is really open for usage and it's not limited.
Now the tool is opening all the policies and what you can see on the left side again, filter, this is now my, again, a hint on use filters. If you are in, if you are in, in those challenges and you want to answer, you want to answer questions. Yeah. The most obvious filters again for cloud resources, but you can see their other policy types. So there are policy types for network, for network, for, for unknown lease and so on. And we also have, and this is, those are two super interesting filter and logic, how it works. So the one thing is the selection.
So for example, there are there's steps where resources are remediable and what we provide then is also the way how customers can do it.
So for example, if I click now on two, their policies out there, which describe a certain status, which is remediable and you, you click on true. You will find them, obviously all the policies that apply that apply to this function.
And, and you can, you can seize this. For example, if you, if you are scrolling now here under the, under the column, it's a check mark. Of course it is because I selected is through.
Yeah, but insides, those policies, and I can get now into one example policies, let's say address security center, product protection monitor is set to disabled and it'll open up and it'll show me here under the commands. Customers can take, including the enter command customers head to do if they want to remediate. So those are things you, you can find here under policies. And also have a look at the other category.
I, I highlighted already is policy subtype. Yeah. I explained to you the pattern of shifting left. So putting security as early in the developer left, like as possible. And you can see your things like besides the network and population things, we have, we also differentiate between one, one and build and build so policies, which are in build obviously can be used super early in, in the life cycle. And if you look at a policy, which is, which is a build policy, it will, it'll also look different.
And I will show you the reason why, because normally policies are set up with our own query language. So everything you can find you can find in, in the tool is based on our own query language. And there's a logic behind it. And right. And obviously when you are in the build phase, the infrastructures called templates, they, they look different and that's the reason why the query, then there looks different. I'm just looking now for, for, for good policy.
Let's see, hope this, I can't find the column I wanted to have, but the point is, if you look, if you search later on in your demo environment and your demo environment is far less complex, you can go into the build policies and look there the second tab, you see the Jason command for the query. Now having explained the logic of how policies are set and let's go.
Now, one step back to investigate is, and you can see here what the engine has done. It copied the last policy I was in, but I will clear it. Yeah. The point as our policies work as queries, and you can query basically everything. And this is, this is beauty of this arch architecture, which I, which I, which I highlighted, which I highlighted before, because everything we get from the cloud providers, we as said, we aggravated, we normalize it.
And therefore it's searchable. And it's searchable by the, by the privacy we have.
And to make a very simple query here, I can put in, for example, under investigate, investigate cloud type is equals. And then basically everything later on, you can see all the dropdowns you, you can select here.
Yeah, you can query. And this is something you can play or play on later on. And everything you type in here can also be saved and you can use the same later on as a policy, if you would like to. Yeah. Not ne not, not necessary for the gaming afterwards, but just as an explanation. And for example, if I now want to see everything, which is, and the cloud region is equal to, let's say bright foot, because yeah, here in the dock region, then you can search for it. This is the logic, how the query looks like or how the query and engine works.
And this is super simple query.
The querys can be as complex as it can be, depending on the use case, what you want to discover, but this is the logic. And if you want to save it, now I can take on a save search. And then you can take the search and nurture to policy. If you want to, this is how the logic works. Now haven't talked a lot about policies. One important point is the compliance part. And this is then the next step. And you need to understand how, how compliance the compliance part work.
Because as explained, we have over 600 out of the box policies and those policies check is the resources you are using are configured in, in a proper manner. And you decide also for the policies as a user, which policies should apply, which not. So it's again, totally up to you.
It's open. Yeah. But the point is why we have also, this policies is to make it easy for customers and to make it also easy in context of compliance and everything you can see here under this compliance checks is based on, on the policies. And for example, if I look now on the GDPR, yeah.
You can see, and I can make the, the down section here. There are 116 policies relevant for GDPR. Yeah. So I can take, for example, now on, on GDPR and then is based up the report. Yeah. And for G for G environment, there are 63 unique assets, GDPR relevant. It doesn't look that good. In terms of a continuation perspective, we have a detailed description below here where the policies are applied to description and you can easily create reports then, and you can also standardize it to have it.
Recurrence report might be super, super helpful for any size out there wants to receive report every Monday based for the whole Azure environment or whatever MI GDPR compliant or whatever.
This is where technology helps. Yeah. Because those, those compliance standards you see in the market and we, we support a lot of them out of the box. Yeah. Those are not written for cloud technology.
I mean, it's obvious GDPR is standard, not written for the cloud. And this is a general standard and what we do, what, what we are doing as part out networks, we look at this standard GDPR. And then as you could also see from the, from the previous side, and then we write the policies, which are important to ensure that your cloud environment, GDPR compliant. And then we match those policies to the standards and then customer ability to have two or three click reporting for the environment. If they are GDPR compliant, this is logic how it works.
And if you look now under compliance, I was on overview. There's some reporting available and understand that you will find all the standards, which we support might be helpful later on.
Also, if you are in the game, just as a hint and obviously everything, and this is super easy, everything which we discover and is again, a policy is against the policy or violates the policy. Of course, it's, it's causing an alert. Yeah. And under alert, you will find also in this, you can see this demo environment. We have here, a lot of alerts there, not the way it should be because we don't want customers to get alert, fatigue, but this is just for demo purpose here. The questions always how to, to operate, to operate technology, to be efficient in it.
But under a alert, you can also see again, filter, for example, if you look for you can select them also true and look which alerts are out there. And so on a lot of things you can do here. One thing I want to point out also for the gaming afterwards is lab was you saw in one slide that we integrate with, with a lot of tools, basically also it's open.
So there's not tool integration, all of the backs available. You can also use back books to write your own integration. And what you can see here is there are some alert rules and your demo environment.
You should only find one alert rule and you can see already here, the notification channel. Yeah. In this case, email here and now, whatever alert rule you want, you want to select, you can.
And I, I just demo it. You can decide which, which policies you want to have, and you can define targets that, and you can then afterwards define the, the alert notification, whether it's email, whether it's slack, whether it's Splunk, just the tools I, I showed you before. So this is how the logic works for alert tools. But basically I was showing you this just as a hint also for the, for the gaming later on.
So, okay. I will not go now into the settings part. Obviously settings is, you can imagine, you can find everything under settings, which the type is supposed to be, but admin, there are a lot of settings around dig to deep into. I will go now into the compute module. So recapping everything you saw before on the stable was now based on the CSP module, I'm now going, I'm now going into the compute module, which is the CWP. So every question in the challenge afterwards, which relates to container security and server, the security, it can be found here.
Now you can see here a lovely visualization. Yeah. And for those of you who are operating with containers already and using Kubernetes, and so on, the one thing which might, or two things that, that pop up obviously is west traffic.
I, I highlighted before already. So this is something we visualized automatically based on the defender, what the defender has learned.
And the other thing might pop up to you is name spaces. Yeah. Which is common, same to use and to abstract also between applications or use cases. However you want to use those name spaces. So this is the rate view where everything starts. So under compute, you can see radars and we have radar of, for host cloud containers and serverless for demo purpose. I will only go into cloud into container and serverless to describe what we are doing here.
Just to finish the navigation pain on the compute tab. Now here, you can see a sub tap, which is called defend. You won't see the defend tap in your environment because I'm admin and the gaming environment doesn't provide settings on defense. So basically in defense, you, you put all the settings, which are important for the vulnerabilities and so on and on the, you will find all the output and this is something you will see.
So you will see basically the rate use and the monitor, and this is where you operate into the challenge.
So, but just as a general learning take with you, everything under depend is, is the input and everything on the monitor is the output. The reason why we have radar is because there are several, there are different use cases for different users in cloud native. So for example, if I'm a developer and I'm responsible only for, let's say those two microservices, I don't need those big radar view. Basically all I want to do is again, getting the results, following my images in, inside my IDE or inside my, my C I C D tool or wherever. I'm just interested in this.
But as a product manager, I am responsible for this whole application. And this case is a similar environment. This is a stock shop. And as a product owner, I have the responsibility and the accountability.
This application is secure. And now in context of containers, what does security mean? So there's three patterns from our point of view, which are super important to, to really, to accomplish, yeah. To protect your container environment. And those few patterns are, are my containers compliant? Do they have vulnerabilities?
And the third thing as the one time do they behave, they, they supposed to behave. And what you can see under the radar view here is basically also color coding based on the, on those three security pillars. So I'm now here on the, on the top, it's now showing colored by compliance. So you can see green containers do not have compliance issues. We also have the run time.
And again, it's just the color coding in this case because we have all this information in the back end. Whether sometimes happens, something happens in the run time or if containers have vulnerabilities, but it taps you also here to prioritize and to look at, I will say the tap vulnerabilities.
It's again, it's here. Yeah. By the way, you can also have some filters here. You should, you might need to use to clear your filters for the serverless part in your day one run, but we get to this now staying on the, on the vulnerability side and what you can get out.
What you can get out of your environment is looking at now certain microservices and containers. So obviously there are some dark red containers. So having a large bunch of vulnerabilities, I can go into it. And I will get a lot of information here from this, from this container or some basic information like three namespaces and the host, where, where on the environment, you can see the hosts where the containers running on and so on.
Now, in the context of vulnerabilities, you can see here as this containers, five critical vulnerabilities, 30 for high risk, 35 medium and low risk opportunity.
If I think no vulnerabilities. And this is from our perspective, super important. Also here to have those information is not only listing vulnerabilities. And this is also something which Gartner just pointed out for the top security project in 2021. So upcoming is they talk about vulnerability, also the whole CSP empire, but they say, Hey, vulnerability management is not about catching everything. Yeah.
So if, if you try to do this, you might, you might have too much effort on this, this, that what Gartner said. So patching, everything is not the best solution. And this is also our view in terms of only providing you a list of vulnerabilities.
Yeah, this is not, this is not how we doability management. So what we provide here is, as you can see, we list already the severities. So the criticalities out there, we provide a lot of additional and contextual information.
So you can see the CBE where this vulnerability out there, I click on it, you will see the source. And in this case, it's the NBD. But for other CBE we might, or the source might come, for example, from, from EBN direct or whatever. And also the reason why I said we have super low falls, positive rate, cause we can bring it all together.
And what we do is we provide customers with the risk factor behind it and also explain why this is a risk factor and provide additional information like the versions was impacted when it was discovered. And C obviously when it was published. So about four years ago by the CVE naming, but a lot of information and we do this for all the vulnerabilities on that, to help the customers also here to prioritize now and takes us also as a small hint for one of the questions later on.
Yeah. It's about risk and prior, prior prioritization.
But the question is also sometimes, okay, now where, where does those vulnerabilities have turned away into my, into my image? And this is what we provide under layers. Yeah. And here also to make it quite easy to, to give context and give the information that developers might need, that you can see in this case, the first layer, it's a base layer. A lot of vulnerability already made it into it. And on the right side, you directly see, yeah, the dock compose visualization, what was done here. And you can see the blue line, which is highlighted.
This is a thing that, which happened here on at file and is made it into my container image. And later on, for example, here at this stage, it's one, one at user. Yeah. There are the, the command in the Docker compose process look different.
So everything which is blue was where I went here for. And this also might help sometimes for, for really getting DevOps and security together because sometimes you might argue that there says, okay, I'm just using base image based providing base image is a responsibility of it. Infrastructure guy.
I don't know how like, but this might be, but latest when you are really on the application layer. So at the, so at the latest station composed process, then the responsibility of the developer. So this might also help foster the, the dialogue between departments, if there's a need to, okay. So we talked about vulnerabilities and, and the layers, how, how we visualize it going, coming from the rate view. Of course we have also some compliance checks and you can see here, this container was compliance.
So it passed even if there's a high ity on it, but based on the rule setting for the demo environment, somebody plates and said, okay, just for the purpose, it was okay.
That which was created as a route user for other containers. And this is then again, something how the policies are set or how you want to set. For example, if I look at the UHS, a catalog B container, you can see, okay, this container has a compliance issue. It's a high risk. And basically finally, finally, it's the same logic there. But in this case, it's a fail image should be created with the non user.
So the same compliance check, which has been done here, but you can really granularly define the policies and the rules, how you want to. And for global purpose, we just use different policies in this context.
Now for, we talked also about one time, you can, you can see here the one time models, which Richard apply. You can directly go into the forensic. You can get all the info about the processes, which, which are running here on.
You can get information about the packages. So basically the complete manifest, how was the container container looks like a lot of info, but not everything now important, especially with the outlook of starting the game, as soon as possible for the game later on, you will also have to use the step monitor yeah. And monitor you can for one time and compliance.
So for example, in under vulnerabilities, also here's a monitor view will provide you a complete overview about your demo environment. Not based now, how I played this in this certain name space or whatever.
And you, you can look for example, how many critical contain images you have deployed. You can search for several specific CVEs, let's say something you want, you want to look at at CVEs, which were released in 2020. And then you can see a complete list of all the, the latest CVEs, which were published in 2020, which apply to your environment. Just examples, how you can play later on in the vulnerability tab and the same of course, and for, for the, for the, for the compliance stuff. So how many containers are compliant? And so on.
Let me look for, I know, wait one also one small hint minute, I now monitor again under images and you can see then of course, the overview about all your images. And we also have tabs for our, and CI I will jump to CI because this might be interesting for you also for when looking at the game and trying to answer as many questions as you, if you're able to, and you want to, and CI those are all bills which are failed or passed, and you can see here, the status that the bid has failed or passed.
Yeah, here, you can find a lot of information about the started this and in the environment, in this case, you will even find, find more and you might want to have a look into the one or the built, which you can find again, under vulnerabilities images, and then CI, okay.
Now the last part, before we can, we can get to the, to the hands on demo for you guys serverless, just as a tip in your demo environment, you might need to clear filters on top of it.
The, what you can see in serverless is also here, visualization, and this visualization, you have to understand how serverless works. So as really roughly explained a short sentence before. So basically serverless is just the processing of any code you write. Yeah.
And you, as a developer, you don't have to care about infrastructure provisioning or whatever. You just wrote over the fence and say, provider, that's the processing for you now, in which context serverless used, because the code or the serverless function where you put your code on needs, needs to know when it should be one. Yeah. And even it's, if it's for one, one, I, so this is electric of serverless.
So it needs basically a trigger and the trigger can come from, from, from anywhere. And this is also why serverless architectures are also so-called event driven architectures.
And this is what we, what we visualize here is, and I will go to the view also here on the top, you can see different color coding. So what happens in serverless is you have a trigger. So something really, which is responsible that your server function is launched. And in this case, it's, that's the trigger and three buckets. So something was put in a three bucket. And this was the event which caused that your, that your servers function replicated device replicated processed code.
And based on this code, other things happen in this case, this function was writing to cloud watch locks and in parallel was writing something to another S3 bucket. Yeah. And so you can build, or basically customers can read complex and super large architectures about serverless.
Yeah. The point is that sometimes equities visibility, and also here, again, the point of permissions, what is this serverless function supposed to do? And actually, what can it do? And if you look now, for example, into one of this serverless functions, you will also get a lot of information here.
Like the cloud provider, the region read is the one time or the language where, where this function is written in. So you can see this, you can see the triggers and you can see the permissions here.
And as, as it was highlighted here, you can see for CloudWatch logs, there are two actions allow. Yeah. And this is a concrete action, which is good. Yeah.
Basically, but there are other functions which might have allow, allow star. So allow all, this might not be good advice to have, because again, zero trust, this might be over permission. Yeah. So you can see, you can find a lot of stuff on permissions and also same logic here. Server functions might have bilities in terms of third party components, or are not com are not compliant in terms of settings there, which causes risks. And also what you can find here, including a description and the course behind it.
So there will be three or four questions around serverless and you, again, you can find, find it, the radars going serverless. You might need to see the pool picture and then look for the, for the several functions. The question relate to and find out what you can see there. Okay. Now let me have a look, our teams room and about attendees. Some have left us that's okay. But we have some other guys still still in, and this is the point where we would be able to start the, the game or the challenge soon. Let me now do, please give, do the following.
I need some time to,
So, so please, everyone who's interested in drawing is a challenge. Stay in the room and need to prepare the team setting. And I will go on quiet, quiet mode for around five minutes and we will meet again at 10 38. Yeah. Hopefully that you are all back in time. And I will use the time to set up the teams for this game, which will start then, okay. Hear you or see you soon. And so game is already over. I will officially stop it now and game oops. And guys it's over. Thank you very much for the participation. And you can see here game is stopped.
A lot of the world has flex, which is good because you can see a lot of questions have been successfully answered. We have a winning team followed by also some, some other good rankings and yeah, the winner is team 14.
And for the, for the winner, I will also paste my, my email into the chat. So please write team 14. Write me an email. If you want to, if you want to get a very small price, just leave me an email and I refer to our marketing.
So please do this if you're interested in it, but in a general now, closing, thanks again for all of you guys who joined in this or who joins this workshop in the morning about the, or the whole theory about cloud native technology and why it has to be secured in different ways and possibly how you secured secure infrastructure with on premise. It, I hope this was clear.
I hope also that this demo more of customer cloud showed you how you can really use technology to, to tackle this no new hurdles and obstacles, which come along with cloud native security and how technology can enable you and your organization to build and develop really yeah. Adapt tech ops organization. Cause from our point of view, this is super important to do so. And as I explained, also in our
Session, it's really all about shifting lift and it's about integrating.
And what technology does in this context is, and I hope, I hope this was also clear is helping you really to get the visibility and from there on to automate, automate, automate, because if you want to do everything manual and if you do it at this stage at the one time, yeah. Then you probably, as an organization might not be able to do this. And this was the whole context of cloud native technology as the risks are.
So, and, and this context why need to be secured in a different way and how technology can help you there. And also in terms of the development of your organization, as that, we are technology provider, prima cloud is our answer. So cloud native security platform with the modules you have seen, or even tried out here.
But one point is that also, which I wanted to, to, to hire is that yeah, technology really speaks for itself. And you are now in a demo environment, which was set up if you are interested to secure your own environment and want to really get life impressions.
Okay, what do I have outside? How can I make those deployments more secure than we are happy to speak to you? That's obviously that's obvious. So reach out to your power of network, account manager, or partner business manager. And we are providing also three tries. We go into your environment and give you some, some guidance here. If you are interested, this it, this from my end. So it's almost 1145. We were good in time. I shortened the game 10 minutes. So almost three hours with just guy like me. Hope you're still life. That winner. Please leave me email.
If you're interested in getting a small price. And again, thank you all for your participation, for, and for the interest in cloud native security and how you can handle it. And I wish you lovely week and a good time, despite COVID 19 things happening, I believe in, in every country in may. So take care, stay healthy and goodbye.
