Welcome to our call webinar, the security and identity challenges of modern. It, it and DevOps done right and secure. This webinar is supported by IC consult co the speakers today are an whose CTO of IC consult and remarketing and principle Analyst at copying a call in this webinar. We will look at a couple of aspects around how can we secure HHL I T and DevOps environments? How can we, what was, what do we need to change? And we will take a specific angle on the identity and security aspects here. Before we start with the content of the webinar, some quick information about Cola and some housekeeping information, and then we'll directly jump into the topic of today's webinar.
In these days, we can't stop business. Every one of us we need to proceed and what we are doing very actively in the same host through, by the way, for IC consult, we are shifting to digital advisory. So from keeping a cold, you can get a lot of services, digital forms, such as technology evaluations, portfolio analyzes, roadmaps, benchmarking, architectures, assessment, strategy, definition, and so on. We are very experienced in doing so online with video conferences, with shared documents, with digital whiteboards, whatever it needs. We also are launching a series of virtual events. So the first three of these are on identity fabrics in the future of identity management in on May 12th, cybersecurity and enterprise risk, early June and cloud first, mid June, that's the topics we are providing there. These webinars are free for the participants, don't list, these virtual events. And we also have virtual learning with our master classes online on a number of topics, such as British access management for the 2020s.
I am essentials. And several more look at what we offer here in that space for the webinar itself, audio control, you are mutual C, so you don't have to mute or mute yourself. You're controlling these features. We are rock recording the webinar and we will deliver the recording as podcast latest by tomorrow, as well as we will provide a slide X for download, and there will be a Q and a session at the end of the webinar. So if you have any questions, you can a ask them at any time using the questions area and the go to webinar control panel, which usually is at the right side of your screen. Apparently the more questions we have, the more likely the Q and a part will be. So don't hesitate to enter your questions throughout this webinar for this webinar. The agenda is for most scooping or cold webinars is split into three parts.
In the first part, I'll look at the changes organizations are facing today when it comes to DevOps and agile, some basics of identity and security as a service, the role identity fabrics play in enabling new digital services, and also how Pam sort of privileged access management piece needs to change. So sort of build the ground for the second part of the webinar, where on believe it. And we'll talk about provided deep dive into the details of securing DevOps environments and the shift to dev sec of so secure DevOps. And he will look at how to efficiently set up security and identity for the mix that infrastructures of today. It needs to run in complex hybrid environments, how to protect, protect DevOps at all levels. And as I've said at the end, then we will have a Q a session. And I'd like to start with some very high level perspective.
So understand also as, as really a, a high level perspective, not going very deep into the detail here, but setting the ground so that we have a sort of a common understanding at a, a generic level of certain concepts we will talk about in this webinars. And so one of the big changes we are seeing, and this is tightly related to agile development, I probably believe without following these architectural concepts, we will not really succeed in agile development. This concept here is about microservices and containers, and we can argue, microservices are not that new. So service oriented architectures are out there for many years, for tens of years already. And in some way, the microservice concepts trust a continuation of what we had early in service oriented architectures. What adds to that is the way we run this entire thing. So what really changes is that on one hand, we have microservices, which are sort of, you could imagine this is sort of legal bricks, and we can use these Lego bricks to construct the application by putting these bricks together in a, in the way we need it.
We also then can exchange to one other brick by a new version, cause maybe the brick wasn't trying enough anymore, or because we feel that another brick, which is maybe larger adds more value, or we want to change the color, for instance, the UI, stuff like that. So we have these microservices which communicate with each other, and then we have these communication also across micro or services from the same vendor or so our own development with external ones, etcetera. The other element which comes in is the way we run this entire thing. And there's a concept of containers which allow to run such service in a very lean manner compared to traditionally running an application server on a host system and then running all these services, as I've said in a relatively complex environment. So containers make this more lean and you can put one or more microservices into a container and then run containers in these environments.
So this is our runtime environment. And then we, we build these microservices in ideally in a agile manner, which includes the DevOps part and factually the, the DevOps part is more around the microservice. So we develop microservices and operate them. That is about the containers. So this is where the DevOps come in. So we have the staff tools, which then coordinate, coordinate this entire area. And below this runtime environment, there might be when we do it in a traditional way, or when we look at what the cloud service provider and what we are doing, then we have maybe in the traditional world still host OS. We have virtualization platform on theos. So we also have all the tools down there we need to manage, or if we go one step further. So how it's very commonly done today, then there's an operating system, which very frequently is run by or provided in an infrastructure as a service environment.
So from the cloud still, it needs to be managed. Whoever provides these tools and then this runtime environment with these containers runs on top of that. But on, at the upper level, we have the staff world. It also could be serverless than it looks again, slightly different, but from a microservice perspective and the question of how do we secure the microservices? The tellers has basically remained the same from, from a overall perspective. We have a couple of areas we need to protect and you see this microservice communication, you see the cross container communication. Apparently we need to protect the microservice itself. We need to protect the com communication between microservices, either within or across the container. We need to protect the runtime environment. We need to protect the DevOps tools itself. So the DevOps workflow, who can do what within this DevOps cycle and depending on how we run that in our own data center in a very traditional manner, or we procured from one of the larger I vendors, depending on that, we also might need to secure more for having a really secure world of DevOps and air trial development.
So this is basically the bigger picture we are doing. And so when we look down at this idea of DevOps, so we have continuous development and we have changes, which then directly go into operations, which allows us in consequence to be agile, we can replace the one other brick, one other microservice. We can add small features in new microservices. We can do all customization in microservices, well segregated. And each of these microservices is APIs. So programming interfaces, we can do a lot of things and can become agile in this work. So on the other hand, when we look at this DevOps cycle, apparently there are various risks which come with this different. It's not that new. So I try to avoid the term new because we have it for quite a while, but with this different way of developing, developing, operating applications and the underlying, that's what I'll outline the slides before the underlying changes in the architecture.
So when we look at the cycle, let's start with the plan on the depth side. So in, in blue, there's the, we plan something we created, we verified, we put it into a package. And so this, in fact, we, we, we plan, we develop, we test, we package it, we release it. So we put it into operations. There might be some configuration it's monitored, and we do the next step. And so this is a continuous cycle of improving by adding more microservices by exchanging microservices, by maybe shifting from an own microservice to a, as a service microservice, whatever else can be in there, but it's not, it doesn't come for free. So we need to understand a lot of things and starting, and I think maybe touches slightly. There are a lot of different components in that. So there's dozens of names, sometimes of tools, which need to play together in such an environment.
But there are other things as well. So we frequently run it on the cloud. And so we need to secure the credentials for the cloud. We not share such credentials, we need to manage it. So if we don't have situations where our AWS or Azure or whatever account, when the credentials are shared somewhere, then we are in trouble. We need to protect that. We will use a lot of standard libraries so that our additional service we are using and latest, I think this hard bleed a couple of years ago, we have learned, we must not trust blindly standard library. They might be out of date. They might be buggy. There might be no professional. Processs around such maintaining and, and, and improving such library. We need to understand that we need to deal with that and to be aware to security. And some of these are more on the securities side, on the coding side, some of them are more on the identity side.
So when it comes to credentials, we are close to identity. When it comes to malware, which might end up in test systems, we are very close to cyber securities, how to protect against malware in these environments, access to infrastructure. So the security for accessing to infrastructure, if you have teams maybe with internal and external developers, how do you handle who can access bot in this entire infrastructure you own? And the stuff you run on the cloud, you need to protect the C I C D flow and all these management tools. And as I've said, there might be a bunch of these tools. So it's that, that you say, I have this one development environment. No, you have, and you have that. And that and that. So there are so many things you might need to manage properly that makes it pretty complex. And at the end, also your services, you create must be secure.
So you need to work with security and identity by design this privacy by design, you need development concept, which I, and I'll touch this in a minute, which is super essential. If you do that, right, all this micro servicing, then every security function, every privacy function, for instance management, every identity function such as registration, such as change the credentials, whatever all these must be, separate microservices, which you use from all your services, which you standardize, which you can easily update and exchange without killing all the other services you created on top. That is what you need to do. So you need a different type of architecting applications. And so from, from here, we, we end at one of these very important points and is interesting. I wrote back in 2007, I wrote an report on application security infrastructures, which talks about providing an infrastructure, which delivers the identity and the security services to the applications you build in a standardized manner.
And exactly that is what we need and what we easily can do in this environment. And which only will allow us to be agile. If we don't do it, we never will be really good in agile software development. So if we need to reinvent security, identity, privacy, and other common features for every service we develop, then this skills, our agility, we need to do it differently to have the time to value, to have the time to market. What does it mean? It means we have our applications when we have done future Porwal and apps we, we might build. And what we need to think about is how can these use in a standardized manner, all these services? So the, the one thing is we, we might use an API such as arrest API, and this API in fact, is an API we provide with our identity and security service layer.
We also might have proprietary APIs, which come with certain components we use, we then use and map to this API. So we can sort of use a wrapper and the same thing as we might even go and say for registration. So if you build as a whatever insurance company, you build a couple of apps and, and, and new web Porwal and stuff for your customers, then you ideally have one component, let's call it the Richard, which provides the registration capabilities. Do it once, use it, you might change the skill, also the UI, the user experience slightly, but it should be always the same technology because then you have a consistency for your customers. And below that, below all these layers, which we standardize, unless in our standard protocols, which go through as a standard protocol, we standardize a set of APIs. We exposes our identity and security layer below that we have our backend applications, which provide these capabilities such as our identity management tools, such as our security services and in an ideal world, if we do that, right, we even can exchange services on the backend by other services, as long as the standard protocols, that's the idea of a standard protocol remains stable and our APIs.
And that is the point where I bring in this idea of optimally using API. So don't build on the proprietary APIs of when a or B, but standardize it so that what you do with your applications remains consistent and stable, even if you exchange technologies. So there are aspects and try to map it. Basically, the idea is abstract, your platform services and your applications, but consistent layer. This is easy to do these days with APIs, with microservice architectures, we are there and you need to do it otherwise you will not be air trial and software development. And when we look at the identity part, we at computer call or while ago defined our standard paradigm for how should identity management in the future look like. And the, what we talk about is the identity fabric, which provides a common set of capabilities by which also provides standardized services to all the digital services and new applications you are building.
So what is it about? And the best thing is here to step back a little and think about why do we do identity management? Because we want to enable seamless success of con consumers, partners, employees, but also services things, devices. So we can extend that list here easily to all these various types of applications. That is what we want to do. That is our target of identity management. And these identities might be managed by and come from different identity providers. So external ones, social logins, et cetera, business partners, directory, service, device management, whatever else. It was a little too fast. And we connect them in various ways to the applications outside. And for doing that, we need a, a set of services, which is the identity fabric. If we extend that a little, this picture, then it is about defining what, which are the capabilities we need here.
So the idea of an identity fabric, and we have a lot of material on our website around identity fabrics, we have videos and other stuff for going more into detail. Our first free virtual conference will be about the identity fabric. So I don't go too much into detail and the interest of time. But basically the idea is having standardized capabilities providing by a set of services. These are our background services, which also should run in a modern architecture because we then can extend it easily. We can deploy our fabric step by step by adding new services. We can run it in a hybrid environment and we can do customization well segregated, separate microservices using the APIs. We obviously connect back to our existing world. We connect back in the standard identity management way by managing SaaS service and digital service button. This is the point which is relevant for this webinar.
There's one additional thing. We also, and we have this say API so we can provide that identity API layer and this a identity API layer, Dennis, what allows all these new services to consume our identity services, and we can do the same with security services. So this is what enables our agile development, which is a foundation for our secure. So we have this agility, but we also have support for our existing world, gradual migration within this idea of an identity fabric. And this is one essential element. We will talk about more of these ideas in his part. And another one is that we have access management for DevOps in place, which means we have also to look at requirements for how can I manage the security there, a privileged access to capability. And in the interest of time, I go relatively fast rooted lives will be available for dollar.
If it's about consistently managing all the types of secrets. So we need something which handles passwords, keys, etcetera, for all the tools, scripts, and all that stuff. And we shouldn't do that with a little bit of key management in that tool and on that as a service platform. And so a wide island of security integrated look for solutions, which are integrated, which provide integration into the DevOps world and into the entire DevOps tool chain. And to continue here, it must support hybrid development apparently. So we might do some things in our own data centers. We might do things on the public cloud. We might shift things back. So development, more data and operations, more data. We need secure walls, which we can well secure for the credentials tool. Tool itself must be secure. We must control, especially with DevOps where we have so many changing people in the teams, we need to be able to control who can do what we need, the audit standard requirement, have the Pam integrate with everything else.
So with our user management, with our access governance, with our security intelligence, and we need to be able to deploy this plan tool step by step. This is a very important element here. And so yes, aside of the, the architectural aspect I touched before, we also need technology, which is privileged access management. And as a last slide, maybe very quickly, one of the things which comes in here is then increasingly, and this is not the holy grail, but it's something which adds this is about femural or shortlist certificates, which can be used in various ways specifically when it's about SSA key management, but also in other areas of DevOps where we can use short lift certificates very quickly going through that might be a topic for a totally separate webinar here. We can avoid that way, manual time consuming configuration of services by, by trust using on demand, trust, and time sort of certificates.
So reduce the effort for, for, for configuration through automation is a short lifetime instead of unlimited reality, which really helps, but there needs to be a certificate authority and these things are not easy to handle, so we need to do it right. We need still break glass access. So what is, if the system doesn't work, we can use policy based access, which helps specifically when developing teams and others are changing continuously, the admins are changing. It's sort of a trust in time provisioning of who has access to our environment. This is one of the aspects around Pam. So basically what, what I tried to, to, to, to explain is we need to, to rethink the way we do architectures to make this entire DevOps world secure and really at trial. But we also will need, need additional tools such as privileged access management, including looking at new capabilities, such as ephemeral certificate with that. We are the second part of the agenda. And I right now hand over Tolbert who will, and this part go far more into detail than I did. Thank you for listening to my part.
Thank you very much, Martin. Yeah. My name is I'm the CTO of I joined I 16 years ago. And my responsibility as CTO is to make sure that our portfolio is up to date, but also that the way we are going to deliver our, our projects are our clients is, is up to date and we are using the right methodologies for that. A few words about IC. So I focuses on the area of digital identities of access management, authentication, authorization, life cycle of identities. And so on that's our core is, but also the area of API management and security, not only in traditional deployments on premises, but, but in, in, in hybrid cloud scenarios. And yeah, and that way I want to share some of our experiences today here with you as structures structured into for subsidiaries with specific focuses more on the business and process consulting side on implementation and integration around digital identities on vehicle support organization, working based on ONAS, providing 24 by services kind of thing, and identity as a service offering and the last company service layer.
I mentioned with this offering as a service there, we learn a lot about how to do depth in a secure way. And yeah, that's, that's very, very important for us for the, for the world I wanna share today. So before talking about DevOps in the modern world, let's talk about how the things was in the past. So our traditional it like something like that. Yeah. We have different network zones. We have a DM, we have an internal network zones and zones in between. And in case we want to provide a new digital service to our, to our users.
It's an iterative approach, right? We are going to plan it, getting budget for it, building it and deploying it, run it. And so, and that's when 18 months later, we start again getting budget for changes, adoptions to have some 18 months later in place, right? This was how I, it was in the past. So is it the traditional plan builds and run approach building means software development. So building, for example, a new API doing specific things, then one very important aspect of this approach is that that team which builds the service is not team which deploys itself, because it doesn't have the privileges to do that in the productive environment, maybe in a development environment, but typically not more than that, but instead of that software package does and hand over to the guys who are responsible to run it. So they not just deploy it, which means getting privileged access to the it system, which runs a new component, but also doing the security, critical tasks around it.
For example, the firewall clearance that the services available from the internet, maybe with the gateway in between is able to access the database, which is somewhere the internal, internal networking zone and, and doing everything which is required to expose and protect that, that API to the internet. Yeah. That's yeah. That's the way how it was done in the past and from a security perspective, I think we did after, after years or decades of learning very well, but, but anyhow, it's all of, you know, the time of, of this approach or even the, the model, it is replaced by agile approaches by DevOps. So what does it mean? All the idea is very simple. The idea is that you bring together development and operations into one team to work together more efficient and yeah, that's it. Well, not completely. We also change the whole approach, how we develop and run it systems.
And Martin talked about, about approach of Microsoft containers a lot. And that's, that is our new standard approach. How, how to develop and software. And I would say the well, one of our clients, we were involved in a, in a project for them. The first step project was a little bit like now it's unleashed it. It's very fast, very efficient, and all the traditional rules have gone away to get speak. So how does it looks like, so do we need with privilege account management while we we'll see, as the idea is having continuous integration and continuous delivery pipeline? What means we have to average, we have a source control system, which does not just have a software artifact for this API, like before, but also the things like infrastructure is code. So instead of, of having the administrator operator in this step team to manually do the work likeor, we are going to automate this work to nearly 100% why instead of having a release every three or six months, we are going to have more releases per day, if you want to do so.
And by having this whole process completely automated. So the build process building the software artifact, the automated test is much test coverage. And then the deployment into the run time environment, often the container based approach in nowadays, meaning that everything like, like Martin explains that everything is in the single container without a lot of dependencies, the outside was, or the perfect Microsoft approach. And we get rid of all the slow operation tasks for all. No, not really. Of course, if you dependencies for example, an internal service, we still need to fire experience. And yeah. Unfortunately decided to go to a cloud, very able to get machines very fast and efficient. We are losing this strict approach of, of dedicated IP addresses and network segments. So it's a little bit challenging getting just the firewall clearance. Yes. To do more, more for that. And then as mentioned, we still have privileged accounts in the cloud, like, like, like the account used to provision that, that infrastructure. So we still have to work in specific situations manually with privileged accounts, automated with provision accounts nearly all the time. The next point is the soft control system is going to be much more critical than before, because it's not just the software, which is packaged and given to an operator, but it's now having somehow, somehow the rules to build the whole infrastructure.
It is a point to access the I C D pipeline, which has access to all credentials required to use the deployment process. So it's much more critical than before then. We have the build process, which involves a couple of systems, not just third party libraries, open source project, but we are going to pull base images from somewhere in the internet and having dependencies, which typically not even not the developer, which is working component completely overseas and well, then we have this, this deployment into the container environment, which is absolutely critical approach because we have more or less access to, to everything running in this, in this whole environment. So going for this Amish it approach without bringing in additional security of controls, well will be very, very risky. So therefore, what can we do?
Oh, sorry. Unfortunately I missed one. So what is happening if we develop our, our, our operators doing a small mistake, typo, and therefore exposing the container with the data store just to internet. Cause it's just one flick you have to change. This cannot happen or would be very stupid mistake, but probably yes, but, but, but did you ever have a look to what databases are directly exposed to the internet? So here we got a, an search from last Friday, what are the Mongo DBS exposed to the internet without authentication? And as you can see, more than 20,000, more than nearly 3000 at Amazon, a lot at, at, at Alibaba. So this are really databases, how they're without authentication. Maybe there are some honeypots, but probably there are also a lot of, of life data available there in the internet. And so this can happen and it's just a small typo today in a DevOps scenario, be aware of that and what is happening, a service like the logging services, for example, get compromised.
If we do not have this network zone, this firewall in place between these containers anymore, we can probably attack the next containers, maybe doing some something on the business logic side or sending data out to another cloud service, not under our control. So these are the things which, which can happen, which are happening out there. And now let's see what we can can do to deal with that. So one approach is that we get control about all the endpoints we are going to expose by still having, having components front in the, to the services. Then of course, we don't wanna have the situation that based on an API gateway, we have these slow change processes by involving other teams to do, to do the exposure to API. But we want to put in a clever bay, clever means self or API. How does it look like require configuration of an API gate?
There's a complex task, but you can provide based on API management solution and template, how an API is exposed. So the publish and of the API on the API management solution is done by Porwal the self for the developers or well API, of course, there's a strict rule set, which applies in addition to that, for example, everything which is related to authentication and authorization, making sure that API is getting, getting the information about the caller client, the end user resource owner, depending on your scenario, but not also everything which is required to enforce a specific level authentication assurance or even identity assurance, then having kind of, of static validation of, and responses, making sure that you prevent specific attacks kindling in place. And so, and they are really high, sophisticated solutions out there which are going and to, to, to provide machine learning to, to get an understanding of what is expected usage pattern of these APIs and, and what this behavior, which is not expected and alerting based on that or blocking based on that.
So this is one aspect, but of course, a lot of, of other things to do, let's have a look on how to secure. See I C D pipeline is a very important point. First of all, to see I C D pipeline, the source control manager. There's no reason to not integrate it into your identity and access management, applying all the best practices there, like making sure that multifactor authentication is in place, that, that you have to define processes, how to get the privilege to work with repository, having reer recertifications on it. So you should follow same guidelines as you do it for your other Chrome jewels in inside your, your, it, it's a super critical system. Beware of that. The next point is about automated code scans. Of course, we did that before and we have to do it in the, in the depth of world as well, that doesn't change, but be aware that that, that there's no reason to not do it anymore.
The number of dependencies is typically growing. And as Martin also mentioned before that you are not just scanning for the vulnerabilities and have a report which is sent to manager, and he's going to plan then print later how to fix the vulnerability, but go for tools which are going to automatically generate or create the user stories for your developer. A job, the, the product owners are always in every planning, aware of all the security findings out there in use libraries and maybe a system, which is able to automatically patch the systems and, and send much access to your repository so that you get an automated fix on it. And if it is direct, then it's automatically enrolled. If it's the test breaks, okay. Then someone has to, has to, to work, to, to solve the issue manually. Okay. Then in specific situations, also the use of HSM component security modules may make sense to protect the critical keys because the developers are able to access productive system.
Maybe you don't want them to get access to the critical key so we can use HSM to protect them and cloud HSMs available. So no need to go on premises for these things. So we fixed a couple of things, but unfortunately there are still more issues out there. Okay. Let's have a look, let's have a look to our, to our microservices and to our container management platform for, for example, Kubernetes. So you should be aware it's a system this which manages your containers is hard according to, to guidelines because it's, unfortunately the security by default pattern is not adapted widely in the industry. Yet we all have to work to work on that and be aware of that systems. Default are not secure that we have to, to work on it, make it secure. The next thing is, as soon as the image is deployed, it should be monitored. Vulnerabilities, still monitored for vulnerabilities. Is there have to be hardening in place for the base images you are using and policies, which are the valid container registries to trust because you probably will not trust all container registries out there on the internet. And you have to protect your images against manipulation. That means you have images and have to verify the signature before deploying deploying them.
And maybe this is not enough. You go a step further. As you remember, you logging services compromised and you do not have any kind of DMZ and something like that in place anymore. You still wanna have a rule which prevents the logging system to access for the business logic, because it should happen. The other way around all other Microsofts are, are calling the logging system to, to, to, to the events. In this case, you want to want to restrict this kind of network rules. And maybe you wanna be aware if there are new processes running or site system access, which you do not do not expect. So there have to tooling in place for these kind of things as well that there are few them vendors out there, which, which can you, can you help on, on solving these requirements? So expect that you need for your C I C D pipeline, a lot of tools to secure them, not just a lot of tools inside them, but also to secure them.
Okay. We solved lot of issues. Unfortunately have one left. We have this kind of, of firewall clearance. We are in cloud services in hybrid in hybrid cloud scenarios. And how can we, can we, can we deal with that because we do not have to single firewall system anymore. We can look to the all IP addresses in parts to get an understanding of which it system can access, which other it system. There are modern approaches, how to deal with this network segmentation requirement. I wanna share one very, very interesting approach. I like, I like a lot. The idea is going away from this approach of deciding which IP address is allowed to communicate with Porwal on another IP address, but going and give labels to your systems. For example, the system can be labeled as database and maybe development production and other systems labeled as logging.
And then you can formulate policy like deny from internet to database because you never expect that a database is called from the internet directly. Or you can formula a policy, deny all from logging because you expect that all your containers or Microsoft are pushing the information to the logging, but the logging should not connect to other systems. And based, based, based on that approach, you have policies which are very, very easy to understand and get rid of this IP address Porwal policy approach, which is well not to understand these approach programs, them typically agent based architectures instead of traditional parameters. And the advantage is that they also work in multi-cloud in hybrid cloud scenarios and not just in the strict network zones of your on premise data center. So this helps us to get, get rid of these problems we talked about before. So unfortunately there's not just one it product with which solves all these issues that we are talking here about not DevOps, product check, but also product stack protecting the different aspects of your it. Systems sounds complicated. Yes, it is complicated, but all everything I mentioned, and this is a very important point, follows the agile paradigm. So follows this 100% automation approach follows this toward everything approach. And this means that that for the developers, the things don't have to be more complicated than before, but from a security perspective, this is a step forward making this step ops word more secure. Okay. Yeah. Thank you. Thank you very much for, for listening Martin.
I are there other questions from the audience so far?
So again, the request to all attendees, if you have questions, enter them now so that we can pick up these questions. I think they're, we already have some, but the more questions we have, the better it is, and we can spend the remaining 10 to 12 minutes, maybe for Q and a, and maybe a little less, depending on how many questions, additional questions we receiv. But so I, I, I saw which search you have been showing, but there's the question of what is this search engine for vulnerable services you have shown on?
Yes. Yeah. This was, this was Showan Showan IO, which is, this is a service which is going to scan out there and detect, which are the parts which are open and pop services are running there and small things like authentication enabled or not. So, yeah, so, so the, the good thing is it's, it's easy to be used, get an understanding if one of your system is not protected anymore, you're exposed something you don't want expose. The bad thing is everybody else who uses a tool knows this as well. So don't expect that nobody is aware of your unprotected Mongo, DB. They are typically 10 cents. I want people which are available. It's very tough.
Yeah. And by the way, show down it out for many, many years. And, and it's interesting when I have talks groups of seizures and are security experts, and, and I ask, you know, who else, you know, show on it's it's I think it's, it's really, it's scary to some extent that maybe 10%, sometimes 15%, sometimes less raise their hands and say, yes, I'm aware of show them and show the computer search for the internet. And an interesting thing here is really, you can even automate that search through APIs. So is really a platform we need to be aware of. I think I wrote maybe eight or six years ago, a block post on that also was showing some search results. So FTP service, which has still the standard password in information on, on there. Horrible. Anyway, there's, there's the next question, which is how does this firewall for, with clouds in areas work? Can you elaborate on the concept a little please?
Yes. So this is an interesting concept. It's I think that some vendors following that approach, a few, a few small number of vendors, 1, 1, 1 company from Tel the idea is that based, based on agents, running on all the systems is of course of drawback of approach. They're more or less taking care of or incoming and outgoing network traffic of this system. And based on this labels, I explained, these agents are going to get the policies which are, which are affecting them so that they can validate this is this traffic allow or denied based on these policies. And, and then the good thing is it's something which everybody can understand. So the policies are understandable for everyone, if you are working very well, this is later. So instead of it addresses in labels, an easy, understandable label and policies, which are easy to understand, like development system does not, it's not allowed to communicate a productive system and vice, and, and then you have two policies already in place, which makes absolutely.
Okay. Next question. Martin entre, while Pam use cases are defined, do you see use cases for identity provisioning, wire dev sex op so wire user groups, or maybe as, as part in, in this environment of dev, so replacing traditional safe service or manage provisioning. So maybe I start and the entree, you might add your thoughts. I don't think that we, we can replace sort of the standard, trying to move a lever processes here. I think the question is how do, how do these processes need to work for a Def sec op environment? So, so the idea of rebuilding it, identity management doesn't make sense even while we see more, more and more agile solutions here, but maybe going, going back to, how do we need to work in these environments? Then, then we need obviously approaches specifically for the, the more privileged users, which for instance, can manage containers, which can manage services or do stuff in these applications, which are far more dynamic. And this is where we really need to think about how can we do the attach to some extent this P but also we need to get better in, in the IGA part, ideally obviously based on, on existing groups or on policies, which then use certain types of users of directors with certain entitlements in that environment lately, do you wanna add something?
Yes. Maybe once. So I think one is that expectations to the process changes a little bit because the expectations from system perspective should be faster, easier, better to integrate and to use them than in the traditional way where maybe a complex change or minor project to integrate the system into the, into the identity access management. So, so this is something which, which changes. And I think the reasons why we have this mobile process doesn't change, the systems affected our, getting more, going to be in, in hybrid cloud scenarios. This would everywhere, maybe 1, 1, 1, in some situations it might work to go from pure API based approach, going over API management and developer Porwal to provide the interfaces, to integrate this identity equity management, to application owners in a kinda self service approach. But I think this is not sufficient for all cases. It's just for, for some of them.
Okay. Another question we have here is sort of in the first part, I talked about microservice communication and trust container communication, and, and how to achieve, how to secure that there was a topic we didn't go more into detail. So, so again, maybe I started and, and you might add some of your thought. So basically what, what a microservice exposes APIs. So the programming interfaces, which allows to communicate with other services, other services can access these APIs and then, then use other services. This is the basic principle concept, which works the same way within the container and beyond the container where you might have APIs, which are more exposed to the public, which you can use in your set of identity or security services, other services, and others, which are more internal. This is basically the idea behind that. So that means that we have a lot of API based communication, which also means we need to secure API based communication. This is where the things really become interesting because it means we need to go to understand what is exposed in which way, what can be accessed in which way. And we need to be more granular in disservice access. And this is also in some way, a paradigm shift for security, shifting away from access control lists to service based security, where we say, okay, this feature can be used, or this function, this API can be used by that person Analyst can be used by other person. So entre, what do you like to add?
So from my perspective, my experience there been talking about microservices, two scenarios. One, one is exactly what you describe Martin. From my perspective, we have to accept that the zero trust paradigm absolutely valid. We have to have the mechanisms to protect these APIs, enforcing authorization and on, in, in, in place. And this all applies with one. Microsoft is calling the next microservice, which is calling the next M and so on, but there are all also the situations where it solutions is built on a large number of small microservices, which are not built exactly to be reusable, but other, for other use cases, but exactly for this, for this it system. And even if I don't like it a lot often, architects don't want to accept this zero trust principle there for, for, for one time, reason and so on. And, but then you have to do other approaches to secure these, these microservices, very small microservice.
There are, there are companies outside, which are focusing, especially on, on that, like, like AquaSec or Noor. And you can use them to, to define exactly which of your containers is allowed to communicate with another container, which processes are allowed to run on the specific container, which part of the size system may be changed, which maybe not changed that we not expect. Right. Right. Operations, things like that. And which there's some machine learning capabilities, then you are getting aware there's something behavior in a way not expected. So one or the other thing you must do otherwise there there's vulnerability in your overall solution.
Yeah. And, and we maybe by the way, to comment the zero addressing, and we can click maybe quickly in that context, or I can pick a, a final question and the zero trust context, I think it's trusted architects and developers need to, to, to change their, their way of programming. So it just makes more sense to program against a security service against an identity service to workers end to end security. And you greatly fail is all the concepts of privacy by design security, by design identity, by design when you don't do that. So it's also probably a lot of change management required. And by the way, yes, a lot of the security of this communication security is not that different from a traditional API gateway and OS plays a wider role, which was one of the other questions we have. Unfortunately, we are right now at the end of the webinar and also of the Q and a session. So we picked most questions. Thank you very much for listening, for listening to this copy and call webinar. Hope to have you soon back at one of our virtual conferences, one of our other webinars look at all the other rich content we have, including our YouTube channel. A lot of interesting stuff out there. And thank you, Andre. And I see consult for supporting this a call webinar, have a nice
Day. Thank you very much, Martin. Thank you. So thank you to the audience and have a nice day, everyone. Goodbye.
