Thank you. Hello, altogether and good afternoon. I'm very happy to see you here in the room. We've got a lot of people looking here and, but also hello to the one which are watching online. So we'll start right by you with, I brought you some zero trust use cases, and first some, some short introduction. My name is Elaine Richter. I'm working, I'm a engineer, business engineering at university of cast. I got a degree there and I'm more than 19 years, somewhere around in BW, in different positions. Right now I am the project manager and did architect for identity and access management or IDM.
What we would call it in oil company. And also I'm a lecturer in, I'm doing lectures in, I am to return university of appliance, science and arts. And today I brought you a little sketchbook and we'll take a look at zero trust use cases from the well-known use cases to the less known ones and the more complex ones.
And I will focus on real world examples. I won't go too much into theory or the formal things or formal compliance, and there will also be I close with some critical reflections on zero trust. And there are key topics you can see there.
We'll look at well known use cases, which I will introduce a workshop. We will look at current use cases, which are also common. Bring your own device, bring your own account. And we'll go on with some lesser known use cases and further use cases, looking into micro segmentation and clarification and close with some critical thoughts. So if you have any questions, just interrupt me please, or ask me at the end. So first of all, what is zero trust?
Well, we have this well known pyramidal security model where we define something which is inside and inside is good. And we've got define something.
Everything else is outside and outside spat. And we input a firewall, et cetera, as a border control in place. And that's a per classical pyramid security model. We do static decisions mainly based on location and network. This is kind lack, flexibility. It's not suitable for distributed scenarios and it's just too simple for today's requirements.
And, but we should keep in mind. It's still better than not having any security at all. So risk regarding all aspects with the modern zero trust security, we will perform better. So we'll take a look at that zero trust security model means we've got interaction between a service and a person or a service and a service. So they both are regarded as actors and the service can mean it. Service can mean software device resource, including data, just everything. And whenever someone or something wants to interact with a resource, we'll always start at a trust level.
Zero we'll apply security measures like better authentication, better authorization, some are controls. And so on till we reach an proprie trust level regarding the interaction, the wanted interaction and the resource. So it's mainly that will start. If we have a trust level pool, we'll have no interaction. If we have somehow better trust level, we allow some interaction and some resources. And if we have a high trust level, we allow interaction with a lot of sources and a lot of interaction. So this should be a risk based approach.
Of course, and the risks are regarding actor, interaction and service define appropriate. Sec security measures. Zero trust needs far more dynamic and Atho aspects than parameter security, because we've got to check this on the fly and not in a static manner. And the technology can be tricky. If you want to go into the formal thing, there's a N standard.
You can find it there. If someone want to see all the definitions, you can look there. I won't go into that. I'd be stick with the more practical part. So we'll start with the use case number zero, the web shop.
It could be something an online shop. It could be also online banking, whatever our use case says, we've got a customer. We are around where somewhere in internet and with the interaction means, look by sell, shop. Something like that. This is formally no hyped as eCommerce in that is known and 10, 20 years, something like that. So what kind of zero trust model mean here? We'll start with zero. Trust anonymous, the anonymous internet user. He can read public informa information from my web, but nothing more.
He, maybe he can do a simple lock in. Maybe we do some cookie magic and he's allowed to access some special information.
If you add some better authentication, now he is allowed to buy or sell at a certain limit. And maybe we even apply transactional authentication so he can change his limits or do really expensive things. Let's say it's online banking or something like that with a really expensive web shop. So why are we doing this?
We do an, the adaptive buildup of trust is defined by the business needs, often compliance reasons, due diligence, credit rating, whatever it's, depending on whatever your is running and how the security measures are often part of the application and the proper identity management is a very central element. And this use case is probably the oldest use case for at least the partly zero trust model. And it's well known and widely used, and probably nobody would call it zero trust. But in fact it is zero trust.
And here we can see zero trust is not only a theoretical concept it's life and use it every day in online banking.
Okay. Let's take a look at next use case. Bring your own device. What is meant by bring your own device most, come bring your own device scenarios, refer to users, bringing their own client hardware like notebook tablets, smartphone to some company for working here though. So the interaction can be summarized as work and use the company's it on this side or some of the company's it. And zero trust model could look like this. If we implement one, we'll start at zero trust.
We've got an unknown user and an unknown device, and maybe he can access nothing except of a company's registration point, but he can access this registration point. There will do some registration, add something information, and we can reach a trust level zero. So the user and his simpler authentica his device, maybe he can now do a simpler or user authentication. Maybe he got a device registration and the partly check off the device so he can access more services, more of the company's it.
And if we want to have a trust level high, we can even do more.
We can do a multifactor multifactor authentication for the user. Maybe we can get the device fully controlled or be put a secured container on the device. Or we just put up a policy that there is no more bring your own device beyond this point. And he has to use the company's device and then he can access the company's specific it service. Why we'll be doing this. Maybe we want to reduce cost for employees, devices, because if the employees using his own device, we don't have to pay for it. Maybe we want to be an attractive, modern startup like employer and not running.
And people can use their own hardware and where we want to have more flexibility.
How we do. We do it from restriction like conditional access and mobile device management to isolation via containerization or application virtualization. There's a lot of technique around which has to put it in place. It's a very common use case for zero trust model. It's well known, widely used, and there's a lot of almost ready to run technology support on the market.
Yeah, you got probably to adapt it to your own situation, but it's a well known use case. So let's go to the more, less known, bring your own account. What does this mean?
Well, bring your own account for collaboration. This is something which you can apply at. It's a nice feature in Azure active directory. Each company has its own active directory. This might be my company. This is another company. And those Azure active directory is built an implicit circle of trusts, which mean I can invite a person which is in another Azure active directory instance, maybe from another company or just from outlook.com or something like that.
As long as the person accepts the invitation, this user is placed somehow as a reference in my company's directory.
So someone of your organization is inviting someone, the foreign user accepts the invitation, and then we've got a reference put into your active directory. After all, we've got a foreign account in here, it's kind of a bring your own account because the person is using his own account. And after all we have to say, you know, nothing about this user, except that someone or somehow accepted an invitation someone sent. So it's a very good situation to think about a serial trust use case model in this case.
So if we got an unknown reference user, so his trust in here, but you don't know who sent an invitation. You don't know the person behind, you don't know any thing about organizational relationships. Maybe you would just want to deactivate this reference account.
Well then someone in your company, will you find someone who is telling, Hey, I'm responsible for that guy? That's my guess.
I, I sent up invitation. Everything is okay, we can accept this. Okay. Then we'll add some information, maybe a start and end date at a very limited range. And we'll accept this guest person and allow him a small range of things possible for collaboration.
Well, then we'll add some more information. Maybe someone is responsible and says, okay, this is my business partner. And we really do work together and do collaboration together so we can add some more rights and access so people can do that. And even we can think about it. If we can have a full life cycle process for this kind of account controlled by an HR system, for example, adding personal and organizational background information to this person, maybe then he can work inside this area inside this cloud, like an internal employee using an internal employee's account.
Well,
Why, why should we do this? Well, it's easy to solve the unknown user problem because of compliance, due diligence, security, whatever. Think about it. It's never a good idea to have unknown users in here. Maybe we also want to do it because of convenience and to implement some kind of lightweight, lightweight collaboration features in our company. The how is a little bit more tricky. We should build up the trust here by adding organizational information, responsibilities control through a high quality life.
Life cycle technology is tricky and it needs to do a, you have to do a lot of do it yourself. There's not so much ready to run tools out there AADA is doing something in that direction. Maybe some others, but you will have to think a lot about what you're allowing, what not and what you're doing.
Okay.
That mean, but we got to step back a little bit and think about it.
It means going into controlled risk in the old parameter security model, we wouldn't have accepted something like this, but here the zero trust is used to organize the lower security levels here in these levels, we are allowing different access
And by adding trust. So now it's getting more complex micro segmentation. What is that? At the beginning?
I said, it's not only serial. Trust is not only for actors being a person, but also for actors being a service, a computer device or whatever, or suggest some code. So let first, let's have a look at the typical way into microsegmentation instead of organization in organizing it through classical technology layers, we put components together for which are working for the same product or business goal. So not all. So we have a database, maybe some application level and some graphical user interface, which we'll put together and we call it product.
Or I would call it service as you like, and
We are doing this. We are applying this for several or all our business goals. And then we'll have a lot of services, small services, microservices, or at least services. And they want to have some interaction so they can work together. Okay. The result is many small services, distributed environments. Micro-segmentation typically run by independently, organized deaf ops teams, which means developer, operations, teams and patterns like loose coupling and resilience, unnecessary to work successfully together.
And even here we should apply a zero trust level. If one service wants to have an interaction with another other service that a trust level zero, there shouldn't be any interaction except of that. There's paid to call, okay. I want to have an interaction between those services. We should. A higher trust level would be. We find someone who's responsible for this service and we've got AED service, clear responsibilities. We got authentication authorization for the service is somehow technology is okay, and then he can access some other services.
And maybe at a high trust level, we got checked services more secured and better IM behavioral analysis per interaction, perhaps. And in this case, this service can do really critical things here or can access a lot of other services.
Yeah, that's a, the similar situation to previous use cases. But this time the actor is a machine or a code, not a person. And that means we've got to implement here, implement a full I IM life cycle management, including those services and services. So each service needs an identity. Each service needs to authorization and so on and services need knowledge about regular expected behavior and unexpected behavior. And controls must be in place to react on unexpected interaction. Yeah. And heavily distributed environments. This become really very hard.
I can tell you, okay, now use case next use case cloudification.
How are we going in the cloud?
Well, we start on premise. We got our trusted area. And first thing we do is some, we rent some private cloud to check out ice cloud, safe place can use it. And we expand our trusted area here in this nice little cloud. Then people think it's good, but with a nice little cloud, we'll have an administrative Porwal or whatever, which is accessible by our internet. And so we've got a private cloud with a public backdoor, which is called Upland Porwal okay.
But at least we, we discover some public parts and oops, we'll discover some public parts and maybe we'll rent some more public cloud services now because this one was nice and it didn't hurt. And then we'll get some, just a few public cloud service, maybe some source services, and then we'll rent some more public cloud services since it's very nice, it's running very good in our company.
And then we'll discover that internet is quite large and there are so many people around to meet. Not all of them are friendly. Some of them are not so not so friendly.
Somehow the situation gets somehow crowded here and where we continue now, either get completely lost or apply it up to date security model because our pyramidal security here is somehow really lost as beyond this point, pyramidal security is, does not work anymore. So we've got quite a journey to discover this, reach this point, but it should be really the last point where you should think about some up to date security model.
So it might be a good point for starting up to date security model, or for example, zero trust security model could play some other security ideas, but at least you should add something except of your additionally than your perimeter security.
Yeah. Cloudification. What does it mean? We've got a cloud service for each cloud service. We have to analyze do an analysis of all actors and interactions that could mean we got a person who is using the cloud service. He's using bring your own device for accessing the cloud service.
We got an administrator who's doing the administrative stuff on the cloud service. We've got people using, bring your own account here. We got services, which calling some APIs of the cloud service and we got whatever you else you have in your company.
So in short, probably all previous use cases are applicable and even some more, well then we'll have to find some suitable security techniques on technologies for each individual cloud service and for the resulting or some the resulting system, which means we've got all these small things here, have to do a security analysis and think about how should they should apply zero trust.
And we have to find a well balanced situation to a certain extent we should respect and accept the selfsufficiency of the product teams.
Usually we are going into cloud services because it's faster, it's more agile, it's easier. And we don't have the overhead of the on premises systems. And if we're doing too much into security and do it too strict, we'll lose this opportunity. And we should also think about, do not get lost in too much distribution. Some compliance aspects need a central governance, but it's really depending on your business, how much central government you want to organize centralized and how much you want to U organize distributed.
So organizational information, general classifications and any general information up in which decision should be made are a good point to organize centrally special decision cases or information next to an individual business case, or are better handed decentralized.
That is something I would give you as giveaway. And now some final words, conclusions, and some critical thoughts, summary. So zero trust allows you to maneuver in unsecure environments and still keep risk under somehow controlled more or less. That sounds good. Some critical thoughts.
Well, zero trust means effort possibly increases costs compared to a classical security approach and cost benefit evaluation seems to be necessary under by advisable. Maybe it's for your use case better to stay in somehow a cheaper and easier to control the pyramid or security model.
Well, okay, next one is zero. Trust is complex. Invasive zero trust often needs to be implemented inside the application, or it has paths which should be inside the application that makes it really complex to run it. And last but not least raw trust is quite a modern technology. That means it's, it's often using non deterministic algorithms.
Since decisions are made situationally dynamically, it's difficult for the user to distinguish something is right or wrong. Why is was yesterday? This access was allowed and today it's closed. And I have no idea why.
Cause my dynamically calculated trust level just lowered, but it's not transparent for the user. And so the user can't participate as a security factor anymore.
He can't, it is for him. There'll be difficult for him to detect abnormal behavior of the system because the system is not exactly not tic. So these three points are points you should think about. And are there any questions? I think we still have some time, six minutes or something like that.
