Contextual Security and Application Control for Virtualized Desktops
October 30, 2018
Jens Schmidt | CSO | deviceTRUST
Tim Cox | Sales Engineering Manager | Ivanti
Daas and VDI continue to provide anywhere, secure access from any device to corporate workspaces. As the user is more mobile than ever before, security, compliance, and licensing requirements demand additional contextual control over virtual applications and desktops. Join this webinar to see how Ivanti and deviceTRUST can help.
Jens: Hello. Good morning. Good afternoon, everybody, and very warm welcome to our joint Ivanti and deviceTRUST webinar. My name is Jens Schmidt. I'm the Sales Manager from deviceTRUST, and I will do some kind of presentation within this session. I have also on the session Tim Cox from Ivanti, and Tim is a Principal Sales Engineer and will do the Ivanti bits and will give you an introduction into Ivanti and into Ivanti application control. Also with me on the web session is Sascha Goeckel, Pre-Sales Manager at deviceTRUST and Sascha will give you a live demonstration of the joint solution, with both the Ivanti and deviceTRUST about the contextual security and application control for virtualized desktops.
From the agenda point of view, and as I've said, Tim will kick off with the Ivanti Application Control piece, then I will give you an introduction into deviceTRUST and deviceTRUST Contextual Security and then that's how we'll do a live demonstration. And then we have some time for summary as well as for your questions and some organizational things. All attendees are in listen-only mode. If you have any kind of question or anything else, please use the Q&A section on the panel and we will get the questions and then we'll answer them at the end of the session in the summary section. So, yeah, this was a quick introduction. So over to you, Tim, for your piece, Ivanti Application Control or at least Ivanti and Ivanti Application Control.
Tim: Okay. Thank you, Jens. Good morning. Good afternoon, everybody. It's Tim Cox here, Principal Sales Engineer at Ivanti, mainly based around the security solutions that we have in our tools arsenal. And of course, they've grown considerably over the last couple of years. And you'll see that on the on the DNA screen coming up at the moment. But just a quick overview of Ivanti, established in '85, privately owned, headquarters in the States, Salt Lake City. Lots of employees now spread over lots of countries. We cover lots of ground. Lots of customers. Millions of endpoints.
And again, not just based on maybe our security portfolio. We have help desk and service management side, asset discovery components in there as well. So we get that true kind of endpoint feel from start to finish. We mainly sell through distribution partners and we have lots on our lists. And we have lots of acquisition since 2012. And as far as the DNA from Ivanti, just moving on to this slide, you know, how do we kind of get here? You know, I came to Ivanti through the bottom route there from SecureWave. We mentioned PatchLink heats into Ivanti. Also as Ivanti really is made up of kind of four kind of major components being LANDESK, which you can see is at the top left hand corner there.
We have AppSense as well, a bit closer to Ivanti on the right-hand side there. We have shavlik that kind of borders the kind of patch management component. Of course AppSense is what we're gonna be primarily speaking around today which is all rebranded and so forth now as we move forward and heat as well. But along there as well, along the way, we've picked up, you know, lots of other organizations who, you know, we've kept their software and, you know, bits and pieces have gone into each of the other solutions just to make them very feature-rich, mature, and battle-hardened is what I like to say.
So that's kind of where we come from through Ivanti. So that name, you know, it's been around for the last two years now, or it'll be two years I think in January coming and it's certainly getting there in terms of being rebranded and a lot of new stuff and there's lots of stuff for me to keep up with.
Just some of our Ivanti capabilities that we have. You know, of course, I'm not gonna go through all of these. You know, we're looking at IT operations, the service management side, operational security is the kind of pillar that I focus on and supply chain as well. You know, we have looking back at that operational security pillar there. We're talking antivirus. We're talking patching. We're talking device and the application control that I put in blue that we're gonna be talking about today.
And you can see a presentation of that from Sascha as well towards the end. So there's privilege management in there as well and the configuration management. Like I say, I won't go through all of these. There's lots of stuff on our website and for further information and we've got Q&A at the end as well. But for the purposes of this, Application Control we're gonna be talking about. And I've always consider Application Control to be the primary defense mechanism. You know, I think by AV patching device control compliment Application Control to give it, you know, as a primary defense and your kind of first kind of hard stop against malware, ransomware, and so forth.
So how can it help businesses? You know, we talk about remove administrative rights. You know, I go into lots of organizations, and I say, you know, our people, local admins, like typically say yes. A local admins are easier to manage. But there the problem is it also opens the can of worms because people can execute bad code. If a piece of ransomware gets on the system, it can escalate and go around the network. So, you know, one of the angles that we come from with our Ivanti Application Control is removing the admin rights. Number two there, helps your course keep up to date on operational security practices. And we can control network access and critical applications. Of course it does a lot more than that.
But no, it's helping protect against ransomware, malware, it enforces License Agreement, controls the user actions, fewer desktop builds. It gives the users applications that they need and keeping those endpoints safe. And again, they're in capitals, all effects without affecting the user's workflow and productivity. You know, it's kind of designed to go into used environments because I gotta like to say.
So some of the key differentiators for our application control, it can run just with an agent. So we don't need to have a server. But it's nice to have the server side for the reporting and a kind of centralized management. It can protect against uninstallation. You know, if somebody needs to have privileges, we can stop them uninstalling stuff because the local admin will try to run uninstall stuff, you know, turn off AV or turn off a firewall, turn off a web filter, or something like that, if they have something else on there.
Again, it's a Windows-based system, physical virtual data center and cloud control. And we always say goodbye to traditional white listing. You know, not a lot of organizations say, "Look, you know, these are the files. This is the whitelist or the hash list. Yeah, this is all that would work." We can do that. but we like to have a more secure environment that give the users control or we call that trusted ownership where the users...you can offer the users control over what they can and can't run. You know, kind of removing that traditional white listing. It's also quick to apply audit mode.
And you can quickly [inaudible 00:08:14] or non-blocking mode as I'd like to call it, so a lockdown mode. Okay? So, again, protection against ransomware, file-less malware as well. Again of the trusted ownership and also control against licensed applications. You can only run this application once. and this is your user. There's lots of other controls that Application Control offers above and beyond.
So one of the first kind of key features, I suppose, when we dig in under application control is the privilege management. Facilitate the removal of admin rights from the enterprise. You know, we try to take...give control back to you as a business as an IT department.
You know, some of the things...you can let them be a standard user, but they can be defragged drive. You can allow them to change the time. You can let them stop certain services. You want to install files from this location. So you can, you know, take control back, but also open certain parts and privileges so that that user can...you know, that the organization is safe against ransomware, but also, you know, the work and business is not affected. So knowing good locations, you can allow that users who run and install certain applications from a repository or certain location which is pretty key.
So we talk about Trusted Ownership here in this next part. So we always talk about the trusted ownership checking here, and that's the default out of the box method used by our Application Control. It relies on examining the NTFS owner of an application. If an application is used to an endpoint, it's owned by trusted owner. If you move that or try to run something else, it's typically denied. It would be denied. And that's how we can control. So, you know, we're seeing system account. local admin, trusted installer. Admins can run stuff because now if you try to move something or take ownership or something is placed on your machine in the context of those owners, it's denied. And that's where the strength is around trusted ownership model of Application Control, okay, and we call it Dynamic Whitelisting.
I'm not gonna go through all of these. You know, it's very, very feature rich and battle-hardened, mature, the Application Control from Ivanti. Just a couple of these that we have. You know, kind of URL redirection in there, which is quite nice. If a user tries to go to Facebook, you can redirect them somewhere else, to another website or maybe a denied page. And we've got license and compliance control. You can only run one version of PaintShop, for example, for Windows 10 support is in there. Virtual Worlds, Active Directory, and OU Support. We support App V, the integration with there with SCCM and Group Policy. You know, we can say we could complement a group policy, if that's something that you're looking at in there. Of course, privilege management and trusted ownership and contextual control. Okay?
So this is where we kind of come from being able to control. You know, this is an example here of, you know, you've got really kind of two types of user for a machine, one is standard. Can't really do much or on the other end of the scale is the full administrator who can pretty much do everything. So what we kind of try to do at Ivanti is get a kind of middle ground there or get them closer to a user or being a standard user but, you know, bringing certain privileges forward or implementing them for the user so that they can do certain tasks.
If you really want to get them full administrator. you know, you get a piece of ransomware that can execute on a local admin machine. You're going to know about it quite quickly. Okay? There's a kind of arrow at the bottom there where we kind of sot and, you know, the software itself has a has a slider like that where you can go from a user across to an administrator and configure policies accordingly to meet your organization's needs. Okay? And sort of removing the admin rights from your desktops.
You know, you could say on the left there Microsoft is a kind of on or off switch, going back to that previous slide. It's either on or off. You are full admin or you're a user. A full admin you can do everything, a user typically can't do that much at all. Where at Ivanti, we give you a lot more switches, dials, allow you to implement, you know, privileges and controls to the users. So not only allow you as an IT organization to take control back but also allow the user to be flexible and carry on without affecting their work.
And just to finish off I think the last slide there for me is the Application Control Console. You know, again, we're talking provision management trusted ownership, easy to manage. You're gonna see some more from Sascha in a moment to start to head back to the ends on this. He's gonna go through some use cases and move around the console in a live presentation. So that's my part. Let me just hand back on full screen and hand...when I get a list. Okay. So it's just...
Tim: Say again?
Jens: Oh, yeah. Love it. Control. Thank you very much. So yeah, thanks Tim. I'd like to pick up on that and give you a quick overview about deviceTRUST and why or what we mean with this contextual security. So, first of all, deviceTRUST is a German-based software vendor. It was founded in January of 2016 with a team working for, yeah, up to 25 years in the desktop virtualization markets with others experience especially in the enterprise with different customers about managing and giving or controlling access to virtual environments, with customers from all different verticals in finance, healthcare, transport, and government, where customers said want to grind or deny access or control access based on context.
Our head office is based in Germany, in Darmstadt, which is quite close to Frankfurt. And we have our development office in Daresbury which is close to Manchester. So where a lot of development Support Center is based. From there we're working with that. We are funded by a large German seed investor since mid of 2017. And I think, yeah, some kind of alliances we have in place. And I just want to point out two in here. One is that our solution is completely Citrix ready certified in all instances for folks in XenApp and virtual desktops and virtual applications, as well as we have an alliance with Ivanti in place where we work together, especially with application control to be able to control access to applications on the contextual basis. And I would like to explain and what we mean by that.
So when we look at the digital workplace, digital workspace, it's mainly all about providing corporate desktops to the user, providing them access to corporate applications, as well as corporate resources. And what we see is it can be done with different technologies like Amazon, Citrix, Microsoft, and so on. So it's independent if it's hosted within the customer's data center or it's provided by any kind of cloud services. But it's all about that the user's able to access his desktops, his application, his data, his resources to do his day-in-day-out work. And one of the...or at least the first security instance or access method clearly is a kind of authentication layer so that the user needs to authenticate against the digital workplace to need to security requirements, which are in place within the business.
And normally what happens is then the user is authenticating. He gets access to his desktop's applications and resources and data based on his role within the business. So means that the user is part of the HR department. And he logs on through user authentication. He gets access to the HR desktop. He gets access to HR applications as well as data and resources and all these kind of things. What we've seen, and that's also the kind of concept of device of office malware is that users now are starting one, two, and also the business one, two that users are able to access the digital workplace from any place with any kind of device from any location. So what we see is that only the, let's say, only the role or only the user authentication as a security there to decide what kind of access the user has within this virtual workplace is not enough anymore.
So we need to consider more detailed information. We need to have more details about the context users coming from to decide what the user can achieve and what the user cannot achieve within the virtual environment. So customers facing issues and facing challenges in fulfilling the existing security, compliance, and regulatory requirements. And this is exactly what deviceTRUST is providing into the digital workplace, into the virtual workplace. So we have an additional security component, which we call deviceTRUST Contextual Security which gives IT department and the business the ability to grant or deny and control access granular to the digital workplace based on many different context information and the user is coming from users access it from.
So when we look in this a bit more in detail what deviceTRUST with its contextual security initially is doing. First of all, we're providing detailed contact information, for instance, or as a first point, detailed endpoint information. So information about the device the user is using at this moment when he's connecting his digital workplace. These are information about the security state of the endpoint, how to information, are there any kind of certificates, what kind of domain memberships the endpoint is connected to, and so on. So detailed information about the endpoint itself. Then in addition, we have information about the network the user is using or the device is connected to.
So what kind of access type the user is using? Is it a validated network? Is it non-validated network? Is the user using a Wi-Fi connection? Is the Wi-Fi connection secure and encrypted or not? All these kinds of information. And then last but not least, detailed information about the locations the user is coming from. Information about the gear location. So detail the location where the user is based at the moment, but also information about the service provider he's connected to and what kind of network location he's connected to.
All these information is what deviceTRUST is providing and putting it into a contextual security layer, which means we are adding what we call actions and triggers to it that you as an administrator of the IT department is able to control actions within the digital workplace to, for instance, provide contextual access. So based on the context information, we are providing grant or deny access to the virtual desktop and control detailed and that's exactly what we are focusing on in the live demonstration in a few minutes, and contextual application access.
So based on the context, the users coming from grant or deny access to specific applications within the virtual workspace, and also control contextual policies, for instance, grant or deny access to resources within the virtual environment based on detailed context information, which device first provides into the virtual session when the user is connecting to his virtual workplace.
This was my short introduction, and I think it's become a bit more clearer and gets more kind of live when Sascha is demonstrating it live to you right now. So over to us Sascha.
Sascha: Perfect. Thank you. So let me show my screen. So let me see if this is the correct screen. Yes. Perfect. And so just a short question, Jens, maybe you're still on voice. Do you see my screen?
Jens: Yeah, it's perfect.
Sascha: It's perfect. So let's get the ball rolling. So what I want to do is I want to show you on three simple use cases we have implemented in the customer within our customer base. But we have a good selection of three nice use cases. And I want to follow up on that with another one, which I want to demonstrate to you how we do the integration with Ivanti Application Control. So I under three use cases, I will really focus on the use case, not on how we do it. But afterwards, I will explain to you how we integrate it in Ivanti Application Control, how application control is using our context we provide. This is something which I will follow up on. We talk about the architecture.
And as Tim has already said, I also want to show you the application control consoles, so I can show you a bit technically how it works. And then I will follow up with a nice summary of that. So I would like to do everything live. So if everything goes not right, I can use a video. So we have everything is prepared in videos as well. And those videos are anyway available on our website, devicetrust.com/ivanti. So let's get started with the first use case. And the first use case is about controlling access to an application is installed on my published desktop based on the method you accessing your virtual environment.
So we have customers asking about when a user is accessing from inside the corporate network, he can access this application. What's happened when the user leaves the application running, disconnects and reconnects from outside? Can we control that? So the first context we using is a context about how you accessing your environment. And everything I say is always it works also not only with Citrix. We also support VMware parallels. We support native Microsoft [inaudible 00:23:53] and so. But my demo is all around based on Citrix but whenever I say now it's all the same with the others. So in this instance, what I'm using is I'm using my UseCase6 user. And this UseCase6 user is using my normal Citrix StoreFront LAN connection.
So I'm doing a normal logon to my Citrix environment. And in this instance, so when the user comes from inside the corporate network, the user is allowed to run a super-critical business application. And at the moment, the user is logging on into the virtual environment. We already know the state, the context state of the endpoint of the location of the network the user is using. And we don't care if the user is using a prime new logon or reconnect. We have always the context available. And at this instance, I'm using a LAN connection. I have here my supercritical business application, which I want to control with Ivanti Application Control based on the context we provide.
I can run this application because this application in this instance is just Notepad++ as an example. I can execute this application because I'm coming from inside the corporate network. So application control is using our context to decide on allowing or denying this application. So what I'm doing now is as a typical one, I'm disconnecting the application or the desktop. Leave the session up and running. And what I'm doing now is I'm changing now the access mode. So I want to come in now from outside the corporate network. In my instance, I'm using a net scalar which is very popular in the Citrix installations.
But it could be also any other remote access solution you're using. Is it a traditional VPN solution? Is it SSL VPN? Whatever you have in place, we don't care because we are 100% integrate fully transparent into your access methods. And we'll talk about that later on how it works. But what's happening now is if I come in now, again, into my virtual environment, we know now the context of the endpoint. And as you see here, as you get the message box, and this can be customized in any language, any text, and the timeout is now 10 seconds, just for demo purpose. The user gets the message that he's not allowed to run this application any more because of the context.
And this I'm trying to execute this application. Now, again, this is Ivanti Application Control kicks in and says, "Oh, sorry, you're not allowed to execute this application based on your current endpoint context you're coming from." And as you maybe know with Ivanti, you can customize this message box. We can even provide context information into this message box. This is everything we can do. And we already have done that for some customers to give some hints why you cannot run this application. Well, that's use case number one.
The second use case I want to show to you is based on...not the access mode, this is not based on, for example, the Wi-Fi network you're using. So I'm going back to my end point here. And as you can see here, I'm connected with a Wi-Fi network called deviceTRUST and is connected and it's secured. So it's WPA2 encrypted and secured Wi-Fi network, which I think that's great. That's from a security standpoint. That's what I want. And if I'm accessing now with a different user...so let me look to my table here. Yes, it's now UseCase2. So it's a different user with a different Ivanti setup to demonstrate that use case.
So and, as I said, before, I'm just doing a normal Citrix log on. I'm still using now Citrix net scale up but could be also internal VPN, whatever you use, we don't care. And what we knew now in the virtual world when we signed in, we know the context of the endpoint. This is what you see here quickly is that we collect the context. The context is available. There's a lot of things ongoing, which I explain later on in the architecture overview. But the reason is now I can run this application is because the endpoint, and that's important, the endpoint is using a secure Wi-Fi connection.
We can even go down and say, "What kind of Wi-Fi network he's using?" Is it a corporate Wi-Fi? Is it a home office Wi-Fi? Whatever. And also depends on your definition whether you decide what is a secure Wi-Fi or not. And that use case is purely about if the Wi-Fi is encrypted or not. Because if it's not encrypted, we want to prevent access to really critical applications because the customer sitting or the user sitting in a public place. I'm still using now a disconnect but I could also do a log off and a prime new log on. So what I'm doing now is I'm going now to my endpoint.
And I'm changing the Wi-Fi network to an very popular, in Germany, it's a Telecom Wi-Fi network. It's a hotspot open public Wi-Fi available in every location in Germany. So like McDonald's, Starbucks, in the train, etc. So come on. So as you can see, I do everything live. So it's connected now. It's perfect. And what we're doing now is we reconnect to my already running Ivanti session. And now what you will see is we provide the context of the endpoint about this unsecured Wi-Fi into the virtual workplace. And Ivanti is using that information now to control access to the application. And that's what's happened now. So I'm back into my session. We already knew the whole context of the endpoint.
And if I try to stop his application, is impossible anymore because application control will deny access because the Wi-Fi network I'm using is not secure by my definition. And as I said, I show you later on how that works technically. Okay, that's also a use case we see quite often in the field. And the reason is it's not normally Notepad++, but it's more critical applications. Like is this HR data? Is this customer data? Is this critical R&D data, whatever. So what customers want to know and want to control if the user is sitting in an area which is not secure by that definition. They need to prevent access. But they still want to allow any other any other application to be executed in the workspace, which is possible with Ivanti and deviceTRUST.
So the next example, or the last demo case I want to show you before I show you how we doing it, it's now we're not talking now about installed applications. We talking now as Tim said about web-based application. So how can we use the context of the endpoint to control access to web applications? So in this instance, I'm going here to another Windows 7 box. So one second, I need to sign in here again. And what I want to demonstrate now to you is...a second, let me just plug in my password. Perfect. So in this instance, what I want to demonstrate to you is how can we control access to your applications just based on the context?
And in this instance, the context we using is what we called validated location, validated network. This is a kind of what we see quite often with customers as well is it say from specific network segments or from specific network locations or [inaudible 00:31:33] locations, the user is able to access this application within the workspace, if it's outside that, sure, you cannot access this because we have regulatory environment for example, to fulfill. So in this use case, this virtual in WAN is now my validated network. And there's a lot of information we can take to make sure it's a validated network or not. But in this instance, I'm using now, again, Citrix storefront. I need to use now as user five. So Sascha-UseCase5.
And in this instance, what we provide into the virtual environment is the information about is the endpoint using a validated network? And if this is a validated network, then Ivanti Application Control allows access to the web application. If this is non-validated network, then Ivanti prevents access to it. And this is something I want to demonstrate to you now. As I said, it's all live stuff we doing here. So we know now the context of the endpoint in the virtual environment. And if we are signed in, we will see...come on. Perfect. We use now a web browser and this instance I use an Internet Explorer, what could be anything else. And I have here my Ivanti. As you can see here, Ivanti Salesforce log on.
And this is my critical application. And if I'm coming from a validated network, I'm allowed to execute this web application. I could sign in now with my credentials and can work with that. That's great. That's what we want because the location is a validated location for us. So I'll use now sign out now or the user reconnect and changing back to this environment. And this in one is not using a validated network location. So in this instance, signing in with the same user again. Let's use a five. As you see, I'm using now here Net-Scale again. But as I said, we don't care what network connection you have. And if I'm signing in now, we knew now that the current location of the user is not validated to access as a web application.
And Ivanti Application Control will prevent access to this application. So let me sign in. So, perfect. And so we are coming into the environment. And, as I said, we already knew the context of the endpoint in the virtual environment. And if the user tries to start now the web application again, so I'm opening Internet Explorer again. I'm going with a mouse. Always sees the Ivanti to my salesforce.com. If I tried to execute that it's impossible because I get an Access Denied message. This is what Ivanti is providing. As Tim was saying before, I could also forward this request to another internet website where you can display a bit more information.
Well, those three use cases should demonstrate to you how the endpoint context is used within Ivanti Application Control to allow access to your installed applications and installed or accessible web applications. By the way, everything I said to you here in the different use cases is also works 100% the same way with fact lines, with laptops. So we can do everything we see here, not only on VDI, but we could also do it on physical endpoints. I want to demonstrate now to you how we technically doing that. So what is the magic behind? So I need to use a different user for that because every user is different use cases behind as you can imagine from the different accounts I'm using. We have quite a lot of different use cases in place.
So also when you have some kind of ideas in your head about a specific use case to you, just reach out to us and we can help you. So in this instance, I want to demonstrate to you that we make the context available of the endpoint not only on log on or reconnect, we can even do this during session runtime. And that's something I want to demonstrate to you right now. So what we do in this instance, I'm signing in now. I have, again, my publish desktop. And what we're doing now is I want to show you first how we provide the context of the endpoint into the virtual environment. There's three different ways we can do it.
You can enable one or can disable the others. So it's all up to you how you want to configure it. But we make the context available as registry values on the hard end user, secured, this is clear. We can also make this information available as environment variables, or you can access it through a command line interface. That's the different methods we're using at the moment. I'm concentrating now back on just registry day more of that. So, as you can see under HKEY current user software deviceTRUST context, you see here, a lot of different contexts information. This is an abstract on what we have or what we're doing outside with our customers.
So that's different context information we provide into the virtual environment. So we have, for example, the validated network we used. We have the access mode we used. We use also things like security state. So what is the security state of the endpoint? And by the way, a user cannot manipulate that. And also clear, we're using the same security mechanism for Microsoft, as Microsoft is using for the policy folders or it's secured by design. And what I want to do now is, I want to demonstrate to you that we can even midsession react on context changes with Ivanti.
So as you can see here, make this a little bit smaller, you can see here we have...we're looking here for context security state, which is protected, which is great. This is what we want, a secure endpoint. And because this is a secure endpoint, Ivanti Application Control allows us to execute this application because Ivanti is using exactly that information, and I'll show you later how that works. We also integrate fully seamlessly in Ivanti environment manager. So environment manager is executing an action here. This is just to create a folder on the desktop just for you to see Ivanti can take the context of EM.
And if I change now the security state to what it shouldn't because this is now a bad state. I don't have an active firewall on my endpoint. And you see the security status is immediately updated that the endpoint is no longer protected. With our conditional access feature, we could now prevent access to your environment. But this is what I don't want to use right now but we could do if it's required. And as you have seen, this EM action desktop folder disappeared because the context has changed. And if I try to execute this application, again, is impossible because the required state, and this is a secured state, does not meet my requirements anymore. So I reset now all this information better to what it should be.
And if we look into the virtual environment, it's immediately updated. We kicked off EM to execute the action. And if I try to execute the business application back, hey, it worked. So this is just the last bit in how we doing it and how we work with Ivanti Application Controls. Or Ivanti Application Control and the environment measure is really using our context to decide what you're allowed to do and what you're not allowed to do or how the user desktop should look like. So now I want to tell you a little bit more about how complicated is it? Is it a lot of things I need to implement? How simply is this? So what I'm doing is now I'm going back here to our architecture diagram.
So let me make this a little bit bigger so you get the maximum out of it. So what you see here on the right-hand side, this is your data center or maybe your cloud or your private cloud where you have your Citrix servers, you Emerson, etc., as you can see here. And on that box, you also have installed Ivanti Application Controls or here's an Application Control Agent running, which do all the magic in allowing or denying access to the application. DeviceTRUST does not need any additional infrastructure. So we don't need an additional Management Server database or all this kinda stuff is not required. Because what deviceTRUST is doing is configured via accrue policies or via environment managers. Also some customers from us using environment manager to configure deviceTRUST to make clear what deviceTRUST should do.
So this is the architecture zone. As I said, no additional infrastructure, just a component you need to install here. This is what we call the deviceTRUST Host. It's just the MSI package. And within the group policy, you define what kind of context you want from the endpoint. This is also an important point. When you see here, this deviceTRUST Client, we don't need to manage that endpoint. This is just a piece of software needs to be installed similar to your WebEx client you're currently using.
What the clients should do, this is something you decide here on the central place. But before we kick into this, I said before, we don't care how the session gets established if it's a LAN connection, VPN, Net-Scale or whatever, is because we're using the virtual channels of your existing remote in protocol. So if you're using ICA, RDP, Plastic Stream, we pluck our technology into the virtual channels of this remoting protocol. And as long as you ICA session can be established through your access or your LAN, we work out of the box. That's great.
So this is good. No requirement onto your network infrastructure as well. But now to a very important point, yes, we need a piece of software on the endpoint. Yes, we need it. And maybe you will think, "Oh, I need to manage this endpoint." And as I said, no, you don't need to manage. It's just an installation. And this client is available as corporate on the endpoints, so we can deploy with Ivanti. Or it's available for, bring your own device. It's just available on our website, click, click, click, install. I think it's two or three clicks.
And that is no configuration applied. Nothing. The magic starts. If you decide here within your group policies that you want to have...and we provided at the moment around about 400 different contexts information of an endpoint. You maybe say, "I only want to get this 10 information, 20, 30, 40 information." This is what you define here in the group policy. The next time the user logs on with ICA, for example, the deviceTRUST Line talks to the deviceTRUST Host. And the host will make some security checks to make sure it's a client from us and make sure the encryption works between the client and host.
And then the host will send down a little conflict and say, "Hey, this is what I want from you." And then the client from us is starting to generate this information in memory, encrypt this information and send it up to the deviceTRUST Host. So if you only want to get 10 information, we only collect 10 information on the endpoint and only send over 10 information. That's important. We're not filtering out here. Another ever important benefit of this architecture is, the deviceTRUST client has an auto-update functionality built in.
So it's just a one-time installation. If the client is installed, you can define by the group policy when you want to update the endpoint fully seamless to the user. So the user even not get any notification about the update. The update works perfectly transparent in the background. And this is a nice technology because this allows you don't care about the endpoints. You don't need to manage the endpoints to get deviceTRUST up and running. It could be bring your own partner end point, whatever.
It's just a one-time installation and you don't need to touch the endpoint for any configuration. That's the architecture when we talk about virtual environments on Windows endpoint and IGEL OS. IGEL OS is a sync client Window very popular now in Europe, and as well, also starting in America. So our software is already part of the IGEL OS, and we will support more sync client Windows at the end of the year beginning of next year.
If we look now too, for example, the iOS technology we are supporting as well with Ivanti is because the iOS app doesn't have virtual channels for using a kind of gateway service which connects the deviceTRUST app with the deviceTRUST host.
Even on iOS, we know the context. And as I said, last but not least, we work the same way. Everything you have seen until now works exactly the same with Windows endpoints. So we have customers that need to make sure that an application is installed on the local endpoint can only be accessed from secure environments, from the home office. So we have police customer and which is a police who want to make sure that when you sit in Starbucks, as an example, you cannot access critical application locally or via the VDI platform. That's what we support as well with Application Control.
And now I want to give you an insight of...so let me sign out here. An insight into the apps Ivanti Application Control console. So one second, I'm moving over here to my admin session. And as you have seen on the architecture diagrams, we integrate everything in the event log. So if I look here for a specific event...let me look for event101. It should be one here we go. And 101 gives you exactly the information, what kind of context the user had when he signed in.
By the way, we can also filter out, for example, geo-location from the reporting with a bit of a German thing, where we can make sure what you report back into the backend system. And if we look now into Ivanti Application Control and how that works and how you can define that, this is very straightforward. So for example, if I look for...this is validated network thing. So let me go into this Application Control configuration. And what we have done is we prevent access to our critical application of which our instance was just Notepad++, but it could be any application as that.
And under validated network, so if the context, and this is what you see here. Let me highlight that before I zoom in. So if the CONTEXT_VALIDATED_NETWORK Equal To true in key HKEY_CURRENT_USER\SOFTWARE\deviceTRUST\Contexts, then Application Control allows this application to be executed. And that's all the magic. If this is a case, so this is how Ivanti uses our context to decide if you are allowed to run this application or not. And that's the same when we talk about environment manager is the same logic. And then if this is the case, then we allow this application now back. That's all the magic it is.
So that's a preview on the application control stuff. And last but not least, I want to show you also the deviceTRUST console and how you can configure this kind of context. How complicated is it to define your context. So I'm going into the deviceTRUST console. And let me go into here. And I can zoom it. And I think we're talking about context and we're talking about action. So but I want to focus on context. And as you can see here, we have lots of different contexts information you have seen before in the user session.
Let me select the security state, for example, and I want to guide you through how simple that is to configure. So first of all, we talk about what's the name of this context in our instance called security state. In a security state, what we do a check here, is the deviceTRUST client is installed. If the deviceTRUST client is installed, we check here is it Windows OS. And to decide the security state, we look for the action send down the spiral. If this is good and antivirus is good and firewall is good, then this context is changing into protected.
If one of those is failing, it goes into unprotected. And if we talk about IGEL endpoints as an example, they don't have anti spyware and the virus and firewall. Here we talk about if this IGEL endpoint is managed by us or not. And this is all what it is. This is the ability to decide the context of an endpoint, in this instance, the security state, and then we provide this information into the registry of the user, application controls using it, environment managers using that as well. And that's all the magic.
It is very simple. We have all this different context as you have seen. Here we have as templates. So if you're interested in that, come back to us and we will guide you through these different examples. I think that's it from my side, from the technical side. So I wanted to give you a sneak preview about how it's working. And what we see here now on the use case overview is now the question is what kind of use case you see with deviceTRUST together with the Ivanti Application Control and UCC.
Here the mixed up from our condition access feature as well so we can control access to your applications and desktops based on the context. We can do this contextual application access as we have seen with Application Control. And as you can see here, there's a lot of other stuff we can do because with this context, it opens up a lot of different things we can do to set for example, the Google Maps home with Ivanti, for example, environment manager. So if you're signing in from your endpoint it opens Google Maps, the home is always the public IP of the server the user is connected to.
And we can provide the real location of the user into the environment. And then with environment manager we can set the nice Google Maps [inaudible 00:50:23] with a real context relocation of the endpoint. Last but not least, everything you have seen works also in double-hop scenario. So if you're coming into one published desktop, for example, and within this publish desktop, you jump to another published application, published desktop, silo service. We even can provide the context into all additional hops you have.
And we talk about double-hop because this is the most used scenario, but we have a multi-hop so we can provide even endless hops you're doing. You always know the context of the endpoint.
Yeah, that's it from my side, from the technical side, and I would like to give back to, Jens, to my colleague to summarize and if you have any kind of questions. I think the couple of seconds you can raise that also technical question. I'm happy to answer those. And but now back to you, Jens.
Jens: Yeah, thanks, Sascha, for the good overview and for the demonstration. I think, yeah, as Sascha said and have shown is what you can do with the with the Ivanti and deviceTRUST combination, it gives you a very granular control about when and how a user can access and provided applications based on your requirements you have in place. So you can take the security of an endpoint and grant or deny access to specific applications based on this information.
What we see in many, many customers scenarios is that they say, "Yes, of course, we want our users to be able to work from home office. We want them to be able to work from different locations and also with different devices." But because we are responsible for the data, we are responsible for the security of the central environment, we need to ensure, for example, that the endpoint the user is using to connect is secured and we don't compromise our virtual environment. We need to ensure the user is in a specific location that he's not able to look at very critical company data because he might be sitting in a Starbucks and some users are behind him and looking on...some people are looking on the screen and find out what he's typing.
And to be honest, I see it so often when I'm going on the train, people leaving their laptops open with critical data and going somewhere within the train, for instance. So with this combination, you can very granularly control the access to applications. As Sascha already mentioned, we have on our website under deviceTRUST.com/ivanti and a couple of more use case videos where you can see different use cases how we have implemented that with our customers, where you can see detailed information and what we are capable to do in much more detail.
And of course, and, Sascha, if you can go to the next slide, please, either you can get in touch with us via our website and you can easily contact us directly. You have also the ability if you want to test drive the solution even as a combined solution, you can request and EVA [SP] license on our website and then we get in touch to get it implemented to initiate it with your use cases you have in place.
So, yeah, that was it as a summary from my side. Last but not least, many thanks to Ivanti, especially to Tim for co-joining or co-presenting on the session. As well as many thanks to you Sascha for the live demonstration. As said, if you have any kind of question, of course, you can type it into Q&A section right now or you can get in touch with us afterwards, and we are more than happy to help you and answer your questions. So many thanks, and yeah, goodbye. Sascha...