Who am I? Well, you can read this one. I'm working at N B w it's a large German energy supplier. And I also give some lectures in identity and access management at university of applied artists and science. And this time we'll take a look at zero trust users. Can you zero trust use cases, and I'd rather take a pragmatic look from a well known use cases from well known use cases up to the lesser known bonds and focus will be on real world examples and situations proven in practice rather than on formal compliance or the theoretical thoughts. So we'll take a look at what is zero trust. Very short one. We already heard something and then some appliances for zero trust. The well best known use case at well known use case is the workshop. Then current use cases, which are very common are being your own device or bring your own account.
And further on use cases are some thoughts on micro segmentation and clarification we'll start well. The old parameter security model is nothing. There's no zero trust. It just means we define something inside, which is good. We could define some old site, which is bad. We got some firewall and some simple controls to have the border control. It's mainly static decisions and mainly based on location and network. Well, it has a lack of flexibility. It's as UN suitable for distributed scenarios. It's just too simple for today's requirements, but we have to say it's, but it's still better than nothing, but regarding all aspects, zero trust security model performs better. Zero trust security model. It means we got some actors which could be a person or service or an application, whatever you call it, I would just call a service. So a human being or a machine, which has an interaction with another service device resource also including data.
And in this interaction model, we will take the decision whenever someone or something wants to interact with the resource, always start at a zero trust level, apply security measures, like better authentication, authorization, more controls, or whatever suitable in your case to you reach a proprie trust level regarding the interaction and the resource. So you start with the poor trust level. You have no possibilities for interaction. If you get somehow better in your trust level, you may have some interaction and you may access some resources and you've got a high trust level. You can access, have more interaction and you can have more resources. That's the simple basis of this model. It should be based on a risk approach, which we've seen at the Siemens model. Very good. And the risk regarding actor, interaction and services define appropriate security measures. Zero trust needs far more dynamic at a hoc aspects than pyramid security.
And therefore technology can be tricky for more formal and complete definition of the standard, but I won't go too much into that. So we start with a very simple and very well known use case workshop, which could also be an online banking, something like that. So you got some online offerings and you got customer, and he has an interaction, which is mainly look by UN sell something in the web shop. This is formally hyped as eCommerce and therefore it's quite well known cause it's old. And we use that. We've got a trust level from zero for high. We got an anonymous user, the anonymous customer. He may read some public information, but nothing more. Maybe we got a bettered user with a simple authentication. Maybe we do some cookie magic and he can may access some special information. We got a better, better user authentication.
He might, he might buy or sell it certain limits so he can reach more service. And maybe we even have something like a transaction authentication. And then you can do things like change limits or do really expensive things. This more or less applies more to a online banking system, but it, we can consider it as an financial online financial online shop could be built, something like this. And why do we do this? Well, adaptive built off adaptive built up of trust is needed. Defined by the business is defined by the business needs, often compliance reasons, due diligence, trick, credit rating, or whatever you will trust, want to know how much you can trust your customer and how much, what payment methods do you offer him or something like that. And how is it done? The security measures are usually part of the application and a proper identity management is a central element.
Okay. That's easy and well known. We do it now for about 10 years, 15 years. It's the oldest use case for at least the partly zero trust model, well known and widely used and zero trust is not only a theoretical con concept here. It's shown that it is alive and it has been alive for quite a while. Okay. Let's go to something more interesting. Bring your own device in the most common, bring your own device scenarios. It refers to a user bringing their own client hardware like notebook, tablet, or smartphone to the company's it. So we've got an employee. The interaction is summarized as work and we got the company's it where this person wants to work. So if, if regarding the trust levels, we started zero, we got an unknown user unknown device and he probably can't access anything. Maybe he can access a company's registration point.
Somehow he does some registration metric and then turns into a user of trust level zero, which means he maybe has a good, simple user authentication device, which is partly, which is registrated and partly checked. And if we go on higher levels, we use a multifactor authentication, maybe put some device control in place, or he put some secure container technology on his device. Or, or we just saying no beyond this point, there's no more bring your own device. And then he can access more things in the company he needs for doing his work. Why we do this? Well as for reducing costs for the employee's devices, maybe we want to be an attractive, modern startup like employer so people can bring their own devices. And of course we got more flexibility and how do we do it? Well, we do some kind of restrictions like conditional access and mobile device management. And if we want to have a harder Porwal, we go into isolation where containerization or app virtualization, or, or we just doing a combination out of this. That is so a very common use case for zero trust model. And it's well known. It's widely used, and there are lot of almost ready to run technology support on the market. Therefore, most people, if they're talking about zero trust model, they tend to focus on on clients like this.
So if we take a look at use case number two, bring your own account, which is typically most prominent implementation and usage is office 365 Azure active directory. Those Azure active directory is built on implicit circle of trust. You got the one for your own company. You got ones for other companies, and there's also something for Azure general. And one user of your user sends alter invitation to users of the other active directories. And the user accepts the invitation. At top. You got some more nice users in your active directories. So, so someone invites users, user foreign users, foreign users, accepted invitation. And then you got reference to a user from a following identity provider, which is in your directory after all, you still know nothing about this user or the human person, the human being, which is behind. So we should do something. So maybe we can go on a more organizational level for a zero trust adoption.
Zero trust means we've got an unknown reference user in here. We know nothing about him. So we just deactivate him. Maybe we can find someone who's telling I'm responsible for this person in this account here of your company. And we add some information, maybe start at end date. And we put him to the, to the trust level of a guest. Maybe we can put in some more information, put some better authentication on him, and we can put him up to the trust level of a partner. And maybe we can tie him to a lifestyle, high quality life cycle process for the person and organizational data and the organizational background. And then we can put on him the trust level of an employee and put on measures so he can access more or less, according to his trust living. Why should we do this because of solving unknown user problems and for convenience, for lightweight collaboration and how build up trust by adding organization, information, responsibilities, and control through high quality life cycles and technology here is really tricky. A lot of do it. Yourself is needed, okay, this, but we should remind this use case means we are going into controlled risk. Zero trust is used to organize the lower security levels. We already are fine with the green ones, but we are able to mix in the gray, red and yellow bones and to organize this on a risk base.
So next use case a little bit more complex. We are going into a microsegmentation, but if you, if you are starting to transform your it for digitalization or whatever, a typical way into microsegmentation goes like this, instead of organizing it through classical technology layers, you put components together working for the same product or business scale here, and we call this one, a service or product or whatever, do this for several business goals. Well then you got several of these small services here and of course they want to have some interactions since the, the overall business code is only reached. If we've got interaction result, many small services, distributed environments microsegmentation typically run by independently, organized DevOps teams and patterns like loose coupling and resilience, unnecessary to work successfully. Okay, but what does this mean for zero trust? Well, if you take a look at trust love, we got interaction, but it's mainly interaction in between machines, which means services has interaction with service.
And if we go in a zero trust model for this use case, we should say, okay, if one service wants interaction with the other service at a zero trust level, there is no interaction. If we want to have interaction between services, we need to build up trust like registering service, clear responsibilities, or some thoughts about authentication authorization that they are okay. And there should be a responsible person who is saying I'm responsible. This is my service. And if you do want some more critical interaction, you should check services. You've maybe you've got checked services, control services, more secured, better identity access management. Maybe you put some behavioral analysis per interaction in place of the, in these services. This is quite similar to the previous use cases, but this time, the actual a machine which make doesn't make it easier implementation often, either in access management for services, including a full lifecycle management for services.
Usually we focus on on human beings. But this time we've got to focus on the machines and services need knowledge about regular and expected behavior and controls must in place react on unexpected interaction. I didn't say anything so far. I didn't say anything. What should be organized, centralized or decentralized, but you need to fulfill the, these things here. So in heavily distributed environments, this can become a very hard, especially if you've got a lot of developers, which are creating independently services and you want to put in there some policies in place, okay, we got micro segmentation and now we take a look at cloudification. The typical way of in the cloud, you start on premises, you got your trusted area, everything is fine. You rent some private cloud, you expand your trusted area into a private cloud and say, okay, the green area is the trusted area.
Everything's still fine. Well, then we discover some public part. We discover that we also have on premise, somehow access to internet and well, the private cloud has some administrative Porwal, which is usually accessible through internet. And that is the kind of a public backdoor. So because still, if we are in run only private cloud services, there's there are some public parts in there. And since we already have some public parts, we rent some more public cloud business and add them in the picture and we rent even some more. It doesn't matter whether it's source pass or yes, it's just some public cloud infrastructure we are putting together. And then we discover that the internet is quite large and there are so many people to meet and they are not, not all friendly people, but they are in between and can access our services, at least at the exterior.
And at this point either get completely lost or applying up to date security model beyond this point. Well, parameter security doesn't work anymore. And this point is a very good point for starting a security similar trust security model. Yeah. How can we, how can we do this then? What does it mean? Well, for each of these cloud services, we have to do an analysis of all actors and interactions with the cloud service. It doesn't matter whether, whether it's a person or it's a machine or it's a device or service or whatever it is. We have got to do the analysis of all these interaction. Probably all previous use cases are applicable and some more. Then we've got to find suitable security, technique and technologies for each individual cloud service and for the resulting assemble. And then we'll get something which looks like this. So depending on the trust level at this moment, you may have an interaction or this service may have an interaction, or it may not have an interaction.
And we've got to find a well balanced situation to a certain extent, respect and accept self-sufficiency of the product teams, the devs teams, which are running those services and do not get lost in too much distribution. Some complaints aspects need a central governance. So maybe you want to have a policy decision point, a policy definition, point more centralized, and a policy enforcement point has to be of course, decentralized. So organizational information, general classifications and any general information, which decision should be made are good points to organize centrally and special decision cases or information next on individual business case, or are better handled decentralized, but you've got to find a well balanced situation. So that's it. Zero trust use cases. We've looked at the well known ones like web shops and online banking, which where zero trust security models are already state of the art. We got to take a short look at the, bring your own something. Similar scenarios. Keep constantly pushing into zero trust, security Tacoma office it, and we've seen business. It use cases in heavily distributed environments like multi-cloud or microsegmentation have a need for zero trust security. There are most complex use cases and there's still a lot of work to be done. And what we've also seen in the two, two presentations before zero trust allows you to maneuver in an unsecure environment and still keep a risk under your control. So that's it. Any questions.
