Yeah, the solutions architect at Ping Identity and I'll be talking about orchestrating zero trust and the paradigm we like to call, detect, decide, and direct. First, I will start with some ground info around my, the buzzwords I have in my title, a bit about zero trust, a bit about orchestration, and eventually tying everything together to a detect, decide and direct model. I'm sure most of the people in the room are aware of what zero trust is, how it comes, and I know I am between you and lunch right now, so I'll try to, to move forward quickly. As we'll know, there used to be a traditional, traditional way of securing everything back in the days where everybody went to an office, worked in an office, used on-prem applications, corporate devices, et cetera. This has changed over time, especially over the last couple of years. I think when it comes to remote access, working from anywhere, working from from home, from a Starbucks, from the plane. If you can afford plain internet applications have moved towards the cloud, not just infrastructure wise, not just using someone else's computer for your data center, but also applications. SaaS applications have become a thing.
APIs have been opened to everyone, both in both directions. Many organizations make use of external APIs. They expose APIs. It's a show me your API's world right now and of course the device pro with all the smartphones, IOT devices working on your behalf where you have to authenticate, where they have to access something on your behalf and so on. So they, there was the need for a new security model for a new paradigm around that, which we like to call zero trust, which where iden, where the identity is the actual perimeter and identity is very central when it comes to establishing security, the trust which we need. The key principles of zero trust. Yeah, enterprise networks don't determine trust anymore. So the, they are part of a trust equation. However, there is no implicit trust due to the network from which a user might be coming. There's always the assumption that malicious actors are also on the same network and network by itself is not sufficient to determine trust,
I dunno where I need to point this. Okay, that way how to determine trust. It's about authenticating and authorizing every user, every device being dynamic when it comes to the policies around authentication and authorization. Making use of multiple, multiple sources of data while making, while making those decisions. So in short that way the alt world of where are you coming from has kind of switched to a world of who are you? And there are many other questions com combined with that as well. We as of course as identity prac practitioners like to put identity into the middle of the zero trust framework, but it's not just identity. There are other aspects to it as well. From networks to applications, the data, the context, the devices, et cetera, which by themselves try to answer different sets of questions from. Do we trust who you are? Do we trust where you're coming from, your device?
Do we trust you to we, we will change the data? Do we trust your behavior or do we trust you to use a specific application or service in order to answer those questions? The identity, not just the identity space, the security space in general has come up with quite a number of different solutions, applications from identity proofing to device reputation, from risk evaluation to labeling data in order to make those different or in order to be able to answer those different questions. The thing is, zero trust is a team sport, so you are likely to pick a number of these different solutions. Some vendors may might claim to have a zero trust in a box kind of solution. That's usually so that you have to pick and choose from different vendors. Depending, depending on the industry in which you are, depending on your use cases, you'll likely have a number of these different pieces in your environment.
So zero trust is a team sport. When we talk team sport, I'd like to make a soccer reference here or football as we Europeans prefer to call it. And again, every organization has their own lineup here from IGA as the goalie to maybe having multiple risk solutions as as your ERs having single silent MFA as your forwards and maybe policy-based access control as your game maker was game maker, I think. So the question becomes here, yeah, you have all the, all these different players in your team, but how you, how do you make sure that they also play together? This is where I'd like to put a stop with regards to zero trust and introduce. You might have guessed that the art of orchestration, as mentioned orchestration does enable you to, you might have multiple different solutions in place, getting all of these different solutions together, bridging the gaps, integrating those without having to heavily rely on development.
And one of the sessions before was about buying and building. This is a bit buy and orchestrate perhaps orchestration does ease the task of integration. The goal is to to ease the task of integration, to enable automation due to the lower amount of coding which may be required. Also stay supportable, being able to upgrade, being able to call the vendor when something goes wrong without the vendor telling it's in your custom code. Similarly, it does allow for, oh, creating user journeys which will look different for all, all organizations for the different types of users may entail an authentication or a different type of authentication. Risk evaluation, going back to an earlier note, taking a different path, doing a multifactor authentication or a step up authentication and so on. The goal is, the goal of orchestration is to create those pixel perfect journeys exactly as you envision them, as you want them to, to look like without being encapsulated in whatever your vendor is offering you without having to do heavy, heavy custom development. It increases UX and security. Both of them are very important. Unhappy users are major security concern as you know, and it helps to be nimble, to be more flexible, to be more innovative. Making changes on this level is easier than ripping out a piece, replacing it and trying to change your custom code. Now bringing the two together is where we talk about the detect, decide and direct paradigm.
Click a couple times. The goal here is to, on the detect side, gather all the information, all the signals which might be coming from the different components of the zero trust team as mentioned before, from risk to network to data classification device, et cetera. Then handing them over to the next step, the decision step where an external authorization engine, a feedback solution or similar, will evaluate the information and feedback their decision and then directing the user accordingly, which may be an authentication step up identity verification in certain cases, deny and depending on the outcome of that direct, do it again, go back to detection, reevaluate, and until you eventually are satisfied with the trust level and allow the user access. This is kind of a circle, so they detect the site direct is something which can be done continuously, which enables a continuous authentication, continuous authorization, as well as continuous zero trust. And with that, I'm in time. I would like to thank you for listening to me and yeah, if you are interested, I'm at Dipping Identity booth. Just a small plug in here. Awesome.
Anyone has any last questions before we move on to the lunch break?
Netherlands? How, how do you see Mame the journey from the modern cloud identity to the legacy on-premise applications but still exist and will remain in the coming years and how this translation will be implemented within Azure Trust set?
The the, there is the, the authentication will most likely be outsourced from a legacy application point of view, which might be a cloud ENT provider, which might be some on-premise ENT provider web access management solution or similar, the key, the zero trust, the enforcement of zero trust would be at that outsourced authentication level, which then can make use of the different signals in order to make the right decisions before handing over the user to the application if the application is flexible or if, if there is the possibility of making changes. This can also be applied to authorization where again, calling up, calling up an orchestration solution to do that circle and authorize the user before giving them some access, certain data or to certain functions would be the the way to go. Great. Thank you.
