Welcome to this KuppingerCole webinar "making zero trust work with the NIST framework". This webinar's supported by Transmit Security. And before we start, I want to introduce the speakers. My name is Matthias Reinwarth, director practice IAM here at KuppingerCole Analysts and I'm joined today by Dr. Sarah Wolff. She is Sales Director for Germany, Austria, and Switzerland at Transmit Security, And by Eric Padua. He is head of architecture for Swiss electronic patient records. How are you, Sarah? And hi, Eric.
Thank you very much for having us great. Hi Eric.
Thank you. So, yeah, and the computer of Sarah doesn't trust the camera. So there is zero trust,
But unfortunately I can't turn this on, right.
But Eric and I will show our faces and, and stand in for also for Sarah there as well. So before we start a quick message from KuppingerCole, I've shown it already very, very briefly. This is the only announcement that I want to do from our side. We are, well, we had to cancel the European identity cloud conference in 2020 for obvious reasons, but we are very positive that in September, 2021, that will be the next incarnation of the European identity in cloud conference, both in person and hybrid. And we are really looking forward to meeting all you people there or virtually for our flagship event then in September. So really looking forward to that. So this is our only announcement here that we want to do. And without further ado, I will move over to the, to the housekeeping for the, for the participants. Mainly the participants are, or the attendees are muted centrally, and we are controlling these futures.
So no need to mute or unmute yourself. This has taken care of this webinar will be recorded or is recorded. The recording will be made available tomorrow. So, so that you can watch it afterwards again, if you want to. And the slide decks that Sarah and I are are using will be available for download as well for the attendees. Very important. Third item on that list is that we have a Q and a session by the end of this webinar. So if you have any questions regarding my part regarding Sarah's and Eric's part, please enter those questions at any time using the go-to webinar control panel. There is a question section in there off-again if you're using the German version and just enter your questions and we will pick those after the two presentations and the final section of this, of this webinar. Okay. So the agenda for today, I will start out with my introductory analyst part, talking about the security assumption of the zero trust approach and how I am can compliment that.
Then Sarah and Eric will take over and build upon that. They will talk about how identity and access management can act as an enabler for working through trust architecture in a multi-vendor environment. And the third part very important is the questions and answers section, where we can provide answers to your questions. And without further ado, I will start with my short part laying the ground for zero trust, right? Oh, okay. So start with, we need to rethink security. And the reasons for that are quite obvious. We have new challenges and they demand for new ways of doing cybersecurity. And the first part that we need to look at our cyber security challenges. And of course we all living in a highly networked increasingly networked world. So we have more attacks. You attack black practice. We have a profitable cyber crime industry, and we even have state-sponsored attacks.
So the pressure continues to rise here. And the picture to the right of course shows that there are some changes due to the pandemic. There is a kitchen table with a laptop on it. And that is the way, how many of us are still working right now. So we have this work from home, bring your own device world. So this is the new normal, and this also requires rethinking security. And we won't go back completely to the world as it has been before. So we have moving towards a cloud first approach. Many organizations are doing that at least massively hybrid environment. And that must be protected as well. So more and more services are deployed from the cloud, no longer run on prem and another tendency, a trend and real big trend that we are, that we are seeing is the dev ops dev sec ops environment, where we have changing ways of software development of architecture, deployment of enterprise infrastructure. It's no longer static anymore. And cyber security has to deal with all these types of volatile environments.
So if we have this situation, how do we build security in such an insecure world? So we need to make sure that we, first of all, lay the foundation for the term trust. And if you want to explain zero trust, we want, we usually like to use a simple picture. We use this cycle that we have here to the right of this picture. We start with making sure that we identify the assets, the users, and the data that we want to protect. We assume Fred, we consider ourselves to be in a network world, which is potentially hostile. So this network is not safe and to achieve access, to give access to users towards assets and towards data, we need to define policies to allow for access or to restrict access. Once this access has been made, we need to make sure that we verify monitor what's going on and also identify the right steps to take when it comes to yeah.
To, to identify issues and to refining all the definitions that we do all the cycle. So it's, it's really a model. So this zero trust is a concept and an architecture model, not just a piece of software, it's really something that you have to build. And Eric, we'll talk about that later on as well, does a combination of technologies and processes to achieve this, to get to a more secure environment. And we need to make sure that we look at the identities, the devices, and the context of users, so that we understand them in a holistic manner. So that also includes determining which networks of data are used so that we take context into consideration, including used access to data, the identity of the user at the network. So with this definition in mind, when we look at the real world, we have a problem.
That problem is the hype around the terms, Euro trust. We are talking about it today and many vendors products have this terms, zero trust related to them. So that also leads to the situation that the lines are blurred, that the definitions are not fully clear and that we really need a proper definition for zero trust. And once we have a strong and valid definition of the concepts, the building blocks and the processes that are required, we can then use that and put it together in an architectural blueprint as a common concept for this architecture. That's, it's behind the seal trust concept. And if you want to combine these building blocks, as we understand that this a, is this something that you build, we need to make sure that this, what you build really plays well with each other. So we need standards and interoperability to make sure that zero trust can be implemented in a reliable manner and that they can, these components are efficiently integrated so that we have interoperability and integration available.
So we want a definition for zero trust and from our perspective as KuppingerCole, and also from the perspective of, I assume from Sarah and Eric, we think a very good starting point is this document that has been created and put out published earlier this year by NIST the national Institute of standards and technology, which is U S governmental. So has a U S focus, but nevertheless is it's worthwhile reading around the world. This has put out many standards around cloud computing, information security, and this document that special publication, 802 0 7 is a perfect primer and CTA on zero trust architecture. But it goes beyond that beyond just explaining the principles and the motivations, it really shows the concept that we are using for this webinar today as well. But it also shows some security concerns of how to implement it in a real world environment, and also provide some suggestions for architecture improvements as the first starting point.
This document defines seven tenants of zero trust. So the core principles of what zero trust is usually we say, we do know what we do not have any more. That is a secure perimeter, but this document does it the other way around. So what zero trust is, it is a combination of east certain tenants that are on the screen right now. So it's, first of all, the resources that we want to talk about, the data sources that advise us many classes of devices, including bring your own device fully hybrid approach. So these needs need to be well understood. Well-described well assessed and integrated. Second tenant is that all communication is secure and the focus is on the word or all communication needs to be secured. That is independent of the network location. And that also means that the, the on-prem network, the traditional secured home network of an organization is also considered to be insecure, to be hostile, to be untrusted.
That means that access needs to be given per session. We trust the request. We apply the privilege of this privileged concept and to the access and make sure that this access is decided. And again and again, and that is done on a policy basis. So we need to define based on the resources page, based on the user, based on the network, based on context, who has access to what, and here, of course, risk adaptive, authentication and authorized authorization comes into play. When you have the client, the resource is this access allowed for that client to that resource. And under which circumstances we need to make sure that all assets are maintained in a way that they keep their integrity and security. So these assets need to be monitored and measured. And if there are issues that they can be mitigated, that also requires a continuous process for authentication authorization, because the situation for the same session might change over time.
So it's dynamic strictly enforced, and it's constantly reevaluating trust. This is a key tenant for zero trust to make sure that you understand the connection at run time, while it is happening. And so that you need context, data metadata, you need to collect this information. You need to analyze it and improve. Also the policymaking, the decision-making time you need to take into account the asset, the asset security posture, network, traffic access requests, and much more. These tenets are the building blocks. The main principles, core principles of zero trust is if you go by these principles, you are moving towards a single trust architecture. We've mentioned that before. The second assumption is that there is no trust in the network. So we do trust in the resource. We do trust maybe in the identity we should, but the network itself is considered not to be trustworthy.
So that includes the enterprise network as being not trusted. That includes the devices, which are no longer owned or controlled by the enterprise, at least partially bring your own device again, that no resource on the network is inherently trusted. That even not all enterprise resources on infrastructure that is enterprise or think of cloud infrastructure. And that makes it clear that these resources are no longer run and owned from, from an infrastructure point of view and remote enterprise subjects, asset cannot fully trust their local network connections or wherever you are. You need to make sure that there's proper protection in place, and that there is a consistent security policy and consistent security posture for assets and workflows across all infrastructure. So that there is a, a unique unified, a uniform way of dealing with the workflows and the assets across the network with the network being untrusted.
My final slide before I hand over to Sarah and Eric is the building blocks that we consider to be important when it comes to technology. So, first of all, we think it's the identity that user I've mentioned. I am guy, this of course is close to me. And here I am really plays out its strengths, strong authentication, strong authentication, risk-based authentication and authorization and trusted user identity. Second, the device, the endpoint management is especially challenging with bring your own device, but this is something that is required when you want to move in that direction that I just described the network that is of course, a building block and we've merged it's untrusted. So we need to make sure that communication is encrypted and authenticated. One building block, of course, are the systems, the infrastructure, the applications. And we need to make sure that particularly with manage them properly here, access governance, access, analytics, seam, and much more comes into play to understand who can do what and who does what.
And finally, if the data that is managed within the systems and applications where users want to get access to, you have to move towards a data centric, security approach. You need to start protecting data. Not only the applications, if you look at how far we have come, I think I am using management is something that can be considered as mature and Sarah and Eric will talk about that. Device management is something where we still all can get better and improve the network. Yeah. As mentioned, not secure insecure, the systems and applications, access governance tuning, is there systems are there, it should be implemented. And data centric security is something that we should think of in general and most, probably more in the future as well. So there's room for improvement there. And if you think of the title of today's webinar, of course, we know that the focus is on that building block on IAM as one key enabler for zero trust. And that is the point where we would like to hand over to Sarah and Eric, but not before. I'm mentioning again, that you can add your questions in the questions panel of the go-to webinars software. Please feel free to add your questions, especially also for the content that Sarah and Eric will present right now. And now I will hand over to Sarah. Eric, are you there?
Thank you very much, Mateus. Yes we are. Yeah. Thank you very much for the, for the introduction and the very distinct overview on zero trust. So maybe from our perspective, as you rightfully said, our focus as Transmit Security is on the acccess management side of the equation. Nevertheless, we've done a couple of projects and, and, you know, large global deployments in a, in a zero trust context here. And which is what we'll talk about together with Eric. I'm very happy that, you know, he's joining us for today's webinar because he has been deeply involved with projects at UBS, but, but he's now also implementing another very relevant and interesting project similar to this one. That's the electronic patient record of Switzerland, which again, you know, is centered around assessing risk in real time context base, and then making an intelligent access decision. But, but maybe to give all of you here on the webinar, then a bit of background on Transmit Security because I'm sure many will not know what we do and how the projects that we do relate to zero trust.
So let me give you just a very quick intro. So we work since many years with some of the largest organizations in the world, and we've been innovating access management for them. And what we started to do seven years ago, we started and, and protected and it's still do until today. We protect online banking identities. So we protect online banking transactions. So security is, you know, at our DNA, usability is in our DNA, but round about three years ago, w was the time when the first customers approached us and said this, you know, intelligent access management that you provide to, to our end customers. We want you to the exact same thing, but we actually want you to protect employee identities because we are moving away from, you know, perimeter security concepts. We are moving towards zero trust hens. We need an intelligent access management solution.
And so, so we started to do the first global implementations in an enterprise context about three years ago. We've done very many by now. And w when you summarize the requirements Martinez, as you rightfully said, in these types of projects, can know people want to work from anywhere. Yeah. Regardless where they sit, they want to collaborate with anybody inside, outside the organization. Ideally, you know, usability has to be high. So people do not want to be forced to use multifactor authentication all the time accessing, you know, every single application. Ideally you provide personalized a personalized user experience, and you only impose security where it's really needed at the same time. Of course, you know, expectation is that security must be as high as possible. And ideally must be dynamic and assessing context in real time to prevent identity theft, which, which is the one of the most, most used techs.
So, so one of the, actually one of the first movers that did a very significant implementation of, you know, intelligent passwordless access management was UBS. And so, Eric, thank you very much for joining today. And, you know, I'm, I'm very happy that you will take us through some of your learnings, but also some of the concepts concepts that you've implemented as part of that project, that at UBS. So if I, if I may introduce the project and then you continue and give us more details. So, you know, as part of often new security paradigm shift, basically what you've said is that, you know, if you touch this, this excess management solution, it modernize it and you want to, you want to move away from passwords entirely, and you want to create an intelligent access management system that can be used by all the employees for UBS globally.
Yeah. Sarah, thanks. Yeah. UVS was interesting. I was actually the application architect behind the UBS uptake of transmit at the time. And at the time UBS wanted to move away from smart cards. One of their main divisions was very strong with smart gratification, but they had to expand that because of regularity re regulations to other countries. And so we looked at something which was a little bit innovative. Then we were looking at mobile biometric authentication to replace the smart cards. And what that is, is basically using peoples or employees, bring your own devices, using a QR code to scan a screen, and then using a device biometrics. So that's a face or finger to allow them to log in. Th the drivers behind that were cost because smart cards are quite expensive and they have quite high maintenance costs usability with, with your own device.
You don't have to carry something extra because people normally always carry their phone with them. We needed to get two factor authentication globally for all business units. It was, it was smart cards were prevalent in one business unit, but other business units were only using straight usernames and passwords. The other thing that was quite, you know, it was quite innovative is location where access control. So UBS being a Swiss bank has strong regulatory requirements to make sure they understood where the user was. And IP based geolocation is, is quite easy to spoof, especially when you're on the internet, but making use of the mobile device that you're using to log in with actually gave us a much more secure environment. Okay. It's not perfect. It's not foolproof, but it, it gives you another level over IP addresses and then identity assurance, making sure that the user is onboarded correctly, because actually it's all very well having strong authentication. But if your onboarding process is weak, then, then that's also not so good. We did an RFI RFP process where we looked at actually 19 vendors around the space. We had a shortlist of five, and then we finally finally chose transmit. So that's just, just a little bit of background of, of where transmit fitted. And I'll give a bit more information in a bit later. Yeah.
So that let's, let's look at some of the zero trust concepts for a second. So, as I said, you know, we've, we've done the UBS implementation. We've, we've done several others. And, and when I look at the one number one content concept that I see is being implemented in most of the cases, it is the one that Mathias presented it's the NIST architect. So that's typically used as reference architecture when moving towards a zero trust model. And when we look at the architectural guidance that NIST provides, we've tried to summarize this here. So essentially the recommendation from listers to have a central policy engine and to central policy administration tool. So that you'll have a, basically a global policy decision point, which, which is then connected to your policy enforcement points. And the idea from this allows for a large variety of third-party systems to provide input, to provide data so that the policy decisions that you make are actually as intelligent as some somehow possible things like you mentioned, taking to your locations, checking IP addresses. We also, you know, transmit the project that we do. We will consume a broad variety of third-party information to do a proper context based risk assessment. If that's something that resonates also with you, Eric. Yeah, definitely.
Yep. And your projects you've done. Yeah,
Definitely both. Both in UVS, but probably more in the electronic patient record where, where we're building something from scratch, we've almost entirely used this model with transmit in the sense of that.
So, so w when we look at the transmit platform, what I've done here is I've, I've met the transmit component to the NIST model. And as you said, so there are certain components of the transmit platform that, you know, are out of the box components that come with it. So w what we supply is a risk and trust engine that can be configured with a very easy to use drag and drop tool. And we will actually take a look at it later. So we'll, we'll finish off the session and look at use cases and look at how easy it is to design policies, how easy it is to change policies. And then what we find particularly important when you talk about implementations in existing, it landscapes is the capability to do policy orchestration, because typically you do have, you know, most of the people on the call here, when I look at the it landscape in with most of our customers, I usually make a joke that, you know, the, it landscape looks like my own audio system here at home, right.
So I've got, I've got, semi-loads the new player here. I've got, you know, I've got new bores of boxes, wifi enabled, and I've got everything in between, right. From, from tape deck to CD, to, to latest Spotify streaming options. So, so the question really is how do you enforce these central policies once you've built them? And this is where the policy orchestration capabilities from transmit are very strong because we can, you know, we can easily integrate VPNs, firewalls, existing MFA tools, anything basically that you have. So maybe Eric, you can, you can give just few shoo highlights from, from your UBS.
Yes. Yeah. Actually, I'll give some examples from my current one, which is the electronic patient record, and COVID-19 testing that we've been doing. But the model above is, is, you know, we're using this, this classic model that the pieces in the middle, the policy decision posting forcement points are all done by transmit. But what w what we've got is for end user customer access through web portals and mobile apps. So we have mobile and web. We have internal application components, which need to be hooked together and, and, and authenticated and authorized. We use an API gateway, but we use most of our use the, the transmit SDK with Jason web token integration. And we also have third party companies coming in third-party partners who, who don't have SDKs through, through our API gateway, and we use, or two tokens and open ID connect as well.
And, and Samuel. And I think that the trick here is, is that the orchestration engine has a very, very strong integration capabilities. You can integrate with pretty much, many components through standards. And also if you, if you can't do it through standards, then, then there's, there's, there's usually a way to do that through custom custom code on the top, right there, you have various inputs into some of these policy engines we use. So for context information, we use context information from the user device. We capture information about the device, and we use white listing to be able to white list the devices that we want to enable the data access policies based on, on roles. But we also have organization information. So for example, pharmacists can only see patient information for patients for that pharmacy and not for other pharmacies. And on the identity management piece, users are onboarded using European health insurance cards later on were planning on using passport scanning. But part, as I said earlier, part of the authentication is, is, is pretty weak. If you've got identity on boarding, which, which is also weak. So part of this specifies that you have to identify the user with two forms of address. So we, we look at email address using one-time passwords and mobile phone number ownership using SMS, a one-time passwords. Again, these two capabilities of validating mobile and email is, is out of the box of transmit.
We don't use risk engine too much, too extensively. Cause I know transmit actually has quite an extensive risk engine, but we do use device fingerprinting, but transmit actually has a lot more in this space, threat intelligence. We don't actually use that yet, but that's on our roadmap. You can, but you can with transmit, you can create device profiles. And there's also the behavioral and risk profiling, which I'm sure Sarah we'll touch on a little bit later activity logs. We, we basically log using as your log analytics and we use information coming from transmit, and we push all of that information into the shore log analytics. And the integration is pretty easy and, and out of the box as well, lastly, we four-seam, we plug into as your security center, which, which gives us some information, but doesn't really give us pop a seam yet. So again, that's probably something that we'll, we'll be delivering later, but yeah, so yeah, to that, but the things that we we make use of pretty much transmit has integrations with and can plug into all of our data sources.
Thanks a lot for that. I think Eric, you are also following this picture here quietly. Yeah.
This is an important slide. I think this slide for this actually says that in order for you to work out who you trust. So, so the, the, the authorization of, of your, your users, you should, you should have these inputs, these source inputs. So access requests use the databases system, database resource requirements of threat intelligence. And, and again, transmit basically has all of these covered. And we, we, we use this. So from an access request perspective, the subject requests, you have context information in the request that comes from the user. This, this can come from the device. So we do device fingerprinting and we do our whitelisting, which again, transmit, performs out of the box. The user database typically has request attributes in them. And so when you make a request, you, you supplement those that request with user attributes information. So things like role organization.
Yeah. Again, that that's used for making sure that pharmacies only see data from their own organization. Again, that's out of the box would transmit assistant database or asset database is about the status of assets and that includes target resources, but also your client device. So, so for example, whether your device is enabled or disabled from transmit, you can actually enable and disable devices out of the box. So if you get, if the device is compromised, you can, you can enable it or disable that from a resource asset perspective, you can also set up static policies based on, on, on the resource itself. So for example, you can only access a specific resource from a specific location. For example, resource requirements really talk about the, the policies and transmit has a very, very rich policy engine. It's probably one of the most distinguishing features of transmit.
So for example, patients have to specify what a medical professionals have access to what data, but that's really a really important policy that you can, you can execute. Doctors could have access to everything, but maybe only dentists have access to the dental records. And, and again, that, that kind of policy complex policy is something that, that is pretty much out of the box with, with transmit threat intelligence. As I said before, we don't really use that, but transmit does have quite extensive user behavioral capabilities. And with the orchestration engine can easily connect to third party threat intelligence tool as well. So yeah, a very interesting slide from nest and, and that's, that's pretty well covered by the product.
Thank you very much for sharing and giving all those insights, Eric. So as you rightfully said, right, w what we are trying to do with transmit is, which is fun. I'm trying to illustrate here with this, with this slide. So you've got different kinds of users trying to access all kinds of different applications on prem apps, cloud apps, hybrid apps, you know, anything in between homegrown third party in large corporate environments, we talk about thousands of applications, right? So, so you'll find that applications that are 20 years old, that I'm Brent knew and everything in between. So what we try to do, and regardless of you know, how old this application is, regardless whether it's a homegrown a third party app, we will always use contextual information to assess risk and trust of this particular transaction in this given context, and then make an intelligent decision.
What type of access management do I need? And th this given context, and we'll, we'll look at that later. And, and, you know, as we, as we mentioned before, specifically, when you're talk about introducing something like transmit to an existing it landscape in an existing environment, the concept of orchestration is extremely important because you will have existing IAM solutions in place. You'll have existing risk management or risk detection solutions in place you will have, and network infrastructure, right. That has been designed with a perimeter security concept in mind. So that means you today do policy enforcement on a switch, on a firewall. And of those, you have hundreds. Most of our customers have thousands of firewalls, right? Deploy it somewhere. I think that the largest amount of policies that I S I've seen was what 3.3 million different policies that needed to be enforced somehow somewhere. And so migrating something like this into a zero trust concept is quite, it's quite an ask. So typically what we do is we try to, we come in, we add the intelligence to the existing environment to then give customers time to, to actually migrate, right. And, and to modernize everything that sits underneath. Yeah.
I, I think, I think UBS is a, is a great example. When, when we looked at replacing our authentication strategy, we had several use cases that we had to fulfill because the end users had access to, to many, or have many ways of reaching resources at UBS. We had things like straight application security. So things like traditional web access management, most of the UBS access to desktops was through a virtual desktop infrastructure. So that was using Citrix storefront internally, but externally we had NetScaler gateways. So you had to come through a NetScaler gateway that also integrated with the Citrix federated authentication service. So Citrix FAS, we had remote access. We had, we had local access. We had to be able to log in for laptops and desktops. And that, that meant that we needed some kind of credential provider on the desktop to hook in with, with Microsoft technologies.
We had VPN gateways coming from the, from the laptops. So we had to integrate with Juniper and, and, you know, with some, some from SAML Federation, their office 365 was another thing that you guys are into now. So we had to integrate with that also cloud applications and cloud mobile authentication. They, they were the main use case that we have to cover. And when you think about all the different ways you can integrate with all those, those, you know, the, the, the, the current points and also the legacy access points transmit was pretty much the only product that could do that out of the box, which was one of the main reasons that it was chosen. And the orchestration engine really helps to be able to deliver all of those integration points.
Again, thanks a lot for those, for those insights here. So we would like to finish off the session and, and show you what the product actually looks like. And we will look at two use cases, which are very common with most of the customers where we do implementations and, and they have also been very common and implemented in a very similar fashion that UBS Eric here, correct me if I'm wrong. But what basically what you see here is the administration interface from transmit. And this is where you build your policies. And so basically you've got these, the strike and drop pop boxes here. And in this particular case, we have a different policy, or we just, we, we separate managers from employees. And depending on whether, you know, you are a manager, you are an employee, there are different requirements towards you when you try to access applications.
And so in this particular example, we also have the risk engine set up here. We do, we will look at, we will score contextual information here. We are modeling the risk and trust engine, you know, in a very easy way. And so the manager is now trying to access a cloud application. It's a modern one that you all know of course this, what you see here now, right? We display this for them or purposes. The user will never see it, but we want you to see that we get that context information. We score the context and because the wet trust is high enough for the manager to access this particular application, he will be directly knocked into the app. Now, if we go ahead and make changes to the policy, because we decided that the application needs to be protected with, with higher security means, or because we think that, you know, certain, certain users can still access, but we request a higher method of authentication here. We can simply change the policy in the, in this, this tab here, and then upon making the change instantly the changes life. And because of the, the new requirements we ask for biometric authentication and this particular case here, then that can be a UBT, or it can be a biometric authentication on the laptop fingerprints that comes with most of the new laptops.
Now, when we look at the same use case, but this time we look at an external contractor that is trying to lock into the same application, because he's an external contractor, the policies are a bit different. So we look at, or we will get that location, information, device information. And we also track things like use cows use count. So how many times have we seen the user before? When did he last access the application and this particular chain case here? Now we make a change to the geolocation requirement. So only if you come from Bon Viton back, you are allowed access to, to this application. If you're looking from anywhere else in the world, external contractors may not, may not access. So in this particular case X, as of being denied, because you come from the wrong location. Now, when we go in and, and make changes to this policy here, what you will see is instantly after we make the change, the contractor will be able to lock him because he actually is, is accessing from Barton. Okay?
So again, you see the, the Trask and risk engineers where we, where we call it calculate risk. Again, we modify some of the risk scoring requirements. We saved them, which were, which will be directly live if we want it to be right. It doesn't need to be, but if we want it to be, we can, we can make changes on the fly. Again. You know, we D we, we display this for demo purposes here. The user will not see any of this. Right. But, but just so that you see, we gather browser information, we give a user information as part of this very simple, you know, SAMO flow. And because of the contextual information that we have, we then make the decision that the user may access the application.
In order for him to do that, we will, we will ask him to use a certain method authentication in, in the way, the way the risk engine, this is set up here is that different methods authentication have a different trust score. So basically, you know, depending on whether it's biometric authentication, or just using them a password biometric is perceived as being more secure. And for certain applications, there is it's mandatory to use a secure method of authentication. That's what you see here. And upon, upon use it of in this particular case, a YubiKey, the contractor is allowed to access the application. Now you can get very creative on how you configure this, because everything that you've just seen can be easily adjusted and configured to your needs. But I think this, this gives an overview how intelligent access management can enable something like something that I could see or, or trust. And it also gives you an idea of what is possible. So that's it, that's it. I'm Eric Erickson, my end, and we will be happy to take questions and have better discuss, you know, distinct situations. You might face implementing something like zero trust and nest here.
Great. Thank you very much, Sarah. Thank you, Eric. Okay. Questions. First of all, the reminder, you can still add some questions. We have already quite list of questions here. We won't probably all cover all of them, but let's start with one, maybe starting with what Sarah said. There's in question, when it comes to, I read it out for an existing environment, you mentioned adding intelligence as the first step. What is the transmit capability that supports that? And how is it done? Does this have any influence on the, on the performance?
So in regards to how we add intelligence, so typically we will make use of tools that you have, right? So anything that you'll have implemented, we will, we will try to compliment. And, you know, as you've seen the demos, we will add a central policy management tool. And we give you the, the ability to easily drag and drop policy changes via this simple to use interface. And we will then make sure that we will connect to your existing environment so that you don't have to rip and replace lots of the things that, that you had to do in regards to performance, we transmit is very, I mean, in terms of performance and what we can assess in real time, what we can do in real time, since we have an online banking background, we've not had a single customer challenging us to the max, right?
So we are used to be, to be highly transactional. And we are used to gather context information in real time, coming from an online banking heritage. It, you know, that's, that's part of the DNA. So I've never seen an enterprise use case where gathering context information was a problem. But, but again, you know, this is, I'm looking at maybe Eric, you did comment here as well, but, but looking at what competitors are doing, it seems that this is not an easy one, right? So doing these types of assessments in real time is actually not easy to do, but, but because of our online banking experience, it's something that we are very good at.
Yeah. I mean, transmit is basically, well how we've used it. It acts as a credential service provider and you would add basically a core to transmit, to say, you know, evaluate authenticates me once you've done that. Then it's got this orchestration engine where you can add intelligence. You can, you can add policies in the, in that orchestration engine to say, right, for this user or for this, this resource, you require two factor authentication, or you require three factor authentication or you request step up. So, so once, once you've got the hook into the, from the application, then adding intelligence is, is actually really you, you, you can drag and drop things in that, in that orchestrator you saw, and you can hook up to other systems very easily. So, so typically as a credential provider, you will need like a, an authentication store. So you'll need something like active directory, or you might need a, an L that repository. So, so you hook up to existing existing systems, but you use the intelligence of the policy engine to, to, to execute this intelligence that, that we spoke about from, from a, from a performance perspective, it we're using in a, in a Docker container plugged into as your Kubernetes. So we, we can scale horizontally. We can use the scaling mechanisms of, of, of Kubernetes to really scale up very intelligently scale up and scale down when we're not in use. So, so it's been, that's proven to be very, very effective.
Thank you. Maybe a question that is closely connected to that. You've mentioned the orchestration part, the Kubernetes pod. How does the network architecture for something like that look like when you are moving towards a zero trust architecture, how would that look like?
Yeah, I mean, to be honest, the, the transmit part of it is actually pretty far away from the network architecture itself, because it's basically application, but in general, for what we've done for the electronic patient record is, is we're using a basic cloud first technologies everything's on, on, on Microsoft Azure, you have to really take on board what I've really had to take on board, the new paradigms of, of, of, of this, this architecture. So, you know, traditional DMZs and traditional perimeters don't exist. We we've basically got a cloud tenant at the front door. We have Microsoft traffic manager and behind that, we have an Engenix ingress controller. So using as your Kubernetes, we haven't as your Kubernetes deployment on the Microsoft as your network, it's on the main v-neck. And then Microsoft itself has controls around what v-necks can talk to which other v-necks and what, what can talk to us to their subnets.
So there are, there are, I would say, layered security. So, so within the, the, the cloud environment itself, you can have v-necks and subnets, and you can control with network security groups or firewalls, what can communicate into there. But the most important thing I think is once you get into things like Kubernetes itself, you have a concept of namespaces and you can deploy your application in the namespace. You can deploy something like transmit in another namespace, and you can control which namespaces have access to which other namespaces, which namespaces can talk to the internet, which namespaces, can't talk to the internet. And so getting that, getting that bite is also important, you know, it's kind of layered, so you have the base network and then you have namespaces and then you have the normal controls, like ingress controllers and traffic managers and firewall. So it's a combination of stuff, but, but you have to really, I guess you assume you're, you're breached and everything has to be basically micro segmented in kind of way. The, the, the, the EKS itself is, is, is, is a container. And then, and then within there, the namespaces get your protected and you control policies between, I don't know if that answered the question, but
Maybe just to add to it, because Eric, what you're describing here is, you know, you've, you've had quite a unique situation where you could actually build something from scratch, right? Because the electronic patient record is a new piece of, is a new digital offering that the ministry of health is launching. And, and so for, for most of our customers, they do have lots of legacy or either they have to carry like, like, like your previous situation, that UBS probably. So in terms of networking architecture, we, you know, of course we, we sent a layer above, right, but being in an intelligent piece of, of excess or an intelligent access component, we would support the existing on-prem scenarios or environments. Likewise, we would support the cloud scenarios and bridge between also, you know, in between of anything. But just to add that and keep that in mind, that's in most projects will actually compliment these existing environments. Yeah.
Maybe one more question. Very short answer, please. But I think that is easy as well, because you've mentioned that you come from a banking environment. Of course, if it was not well done, then transmit component as a middleware component could be a bottleneck. That's why I assume that this scales as well, when it comes to the platform itself, but also information storage and throughput to the individual components. So there's scalability built in there as well. Yes, of course, of course.
So we've got, you know, we, we do global deployments for, for companies like HSPC. And so if they are customers cannot walk into their online banking applications somewhere in the world, that creates a tremendous problem. We, we have been challenged significantly by, in Vegeta gods by that, by our large corporate clients.
Okay, great. Thank you for that answer. So from, from my of view, that time is almost over. I would like to thank Sarah and Eric for sharing their insights and the experience from, from these actual projects that ups and for this patient records, this was patient records. So thank you again. And we will hand over the questions that have not yet been answers of course, to Sarah and Eric, so that the feedback can go back to them. So thank you, Sarah. Thank you, Eric.
Thank you very much for having us, and we'll be happy to respond to all other questions that we couldn't discuss. Yeah. Yeah. Thank you very much.
Excellent. Thank you very much. And a bit unusual at that point of a baby. Now that I have one more slide to share, this is the final webinar for this year. So it was quite a year. So what a year is really true. We did 68 webinars in 2020. We had more than 10,000 registrations, which is nice. We answered more than 300 questions and including the ones of today would be even more. And we want to give you more than 100 reasons why 2021 will be an exciting year as well, including new webinars, but also the EIC. So from our point of view, and I think I speak for Sarah and Eric. We wish you a very happy holiday season, peaceful and prosperous new year, and we want to see you again and hear you again in next year, stay safe. And that's it from our side. Thank you very much again for being our attendees today. And I'm looking forward to the next webinar soon. So bye-bye.
