SANS Zero Trust Solutions Forum 

Transcript

Thi Nguyen-Huu:

Hi thank you. I’m good, thank you Matt

Matt Bromiley:

Awesome. All right, I’m going to hand it right over to you. I know you’re going to be presenting so I’ll give you a chance to get that set up and whatnot. But, in the meantime, folks, Thi is here to talk to us today about “Beyond passwordless ‘Zero trust’ always verify security with no user action.” I think this is going to be a really neat approach about a way to go about this particular issue. So, with that said, Thi, the stage is yours. Take it away.

Thi Nguyen-Huu:

Thank you, everybody, for joining us today. My name is Thi, and I am the founder and CEO of WinMagic. You can see, I have no magic wand. But, we at WinMagic, we want to be magicians, like WinMagicians so that we can give you some new ways of thinking like, not magic, but probably a smarter way of thinking. For example, today we are about in the zero-trust conference, so I would like to ask: is zero trust really needed? I mean, it is so complicated, as you can see. So, is it really needed to prevent all attacks, online authentication attacks we know today?

If you think about all the attacks we know in the past years, I think you can see that the attacker was not the authorized user and the attacker did not use an endpoint which belonged to the authorized user.

If we just simply verify accurately either the user or the endpoint, none of those attacks would have succeeded. I mean, we do some complex things like zero trust and so on, but is it really needed? I think this question will be thought-provoking and, hopefully, it will be useful. Thought provoking is also the idea that we claim that our solution has zero trust security. Actually, we say is the most secure; more secure than everything you know out there. And we combine that with the best possible user experience — meaning, no action: the best possible experience there can be. How can we help them both? Let’s go through the presentation — I hope you like it.

As you know, everybody is worrying about security. 98% of all businesses worry about authentication, more secure authentication. But, I would think that 100% of all companies want to ease user’s burden. What is the user’s burden in online authentication? Well, those are the log-ins users have to do many times during the day. We would like to differentiate between two types of logins: endpoint access and access to everything else because we propose that endpoint access will give access to everything else. It means, with regard to users’ burden, you will have 100% no more burden for online authentication: no user action is required. That would satisfy easing the users’ burden big time.

The question is, of course, can endpoint access give access to everything else? To answer that question, let’s go back to basics. Before, everybody used a password. And, as you know, the user entered a name and password to the endpoint, and you went to the server. It’s very easy for attackers to attack and it’s very difficult for users to remember passwords and long and many of them. Of course, people go to passwordless authentication, which is better than the traditional MFA. Passwordless authentication, or public key-based authentication, relies on a device in between. It means the user doesn’t authenticate directly to the server, but it uses a device because the device can perform very strong public key-based authentication like FIDO or certificate-based authentication. That is very strong against an attacker to attack.

On the user’s side, the user only has to do some easy local gestures to tell the device to authenticate to the server. This solution, passwordless authentication, is very good against the password before: very easy for the user and difficult to attack. In addition to passwordless authentication, we know that Federated Authentication is used because it saves the user from having to log into 10 or 50 applications every day. The IdP server will take care of that. But, you see, if users still have to log in 50 or even less now and then, many times during the day. We can ask, can we eliminate the local gesture and achieve no user action? Let’s dive deeper into it.

The idea is, there is authentication at the IdP server that takes care of all federated authentication. Can we achieve all that without user action? Let’s say we have the endpoint and we have the server. So, we build a MagicEndpoint Center to coordinate it and we say: on the endpoint, the endpoint continues to verify the user. That’s what the endpoint has always been doing since it ever existed — it verifies the user. But now, for the remote access, the endpoint will build a so-called entity, user and device, and make sure it is presented or it uses a key, which is unshared, which nobody else in the world can use. This can be done because you use the IdP at the TPM and the TPM will have a key which nobody else in the world, no other device can have that key. We can do so that the key doesn’t exist until the user logs in. Meaning, depending on the credentials of the user, we will do so that, in the TPM, there is a key which only the TPM has and it doesn’t have it even before the user login and it will be erased when the user logs off. That unshared TPM key is the foundation so that we can do the next step, which is the endpoint will create a persistent connection to the IdP. Because of the user’s unshared private key, nobody can break it — nobody can fake it. Using cryptography, you can see that the whole world would need hundreds, if not thousands of years before it can break just one endpoint. Now, through this persistent connection, the endpoint will update the IdP with the security posture of the endpoint, if it’s unpatched, if it’s not encrypted, and so on. But, more than that, you can see the endpoint, no user presence, it will inform the IdP if the user logs off/logs on, if somebody else logs on, or if the screen is locked, and so on.

Even more than that, everything the user does with IT goes through the endpoint. So, the endpoint knows the user is going to any application or service. It knows, for example, that the user is going to Office 365 and not to a VPN, Jira, or Salesforce. It knows all that. The IdP actually can do more than just the IdP: it can control the endpoint, and it can log out the endpoint if there is an indication to do so. For example, the IdP will take more environmental signals from all the ecosystem partners and vendors to build a very concrete, very accurate image about the user and the device in real-time without user action. Equipped with this information, the IdP can grant access from the user to all service providers, again without user action, knowing that the endpoint is authentic and the user is authentic in real-time.

The idea is, again, you, the user, log in to the endpoint, ideally with MFA, even at pre-boot authentication and at OS login. After that, the endpoint will take care of all remote authentication for the user without use action. You may ask, can it really work? Well, we did not invent everything. We take the industry’s best ideas and add some innovation to them — mainly to increase the endpoint’s workload and, at the same time, decrease the user’s workload. Decrease to the extent that the user doesn’t have to do anything. It is possible: that’s the new way of thinking we want to propose.

The three best ideas, you know, are, for example, FIDO, FIDO uses public key encryption that replaces all the obsolete MFA you have been using. It’s clear the US Government is discontinuing all other MFA except publicly based authentication by the end of 2024. It’s real, the entire world, security-conscious companies, is going in that direction. But now, what does a FIDO verification prove? If you use FIDO on the phone, it only proves that the phone is authentic. But, what you want to do is, you want to verify the user and the endpoint. We create this entity — we build it so that the entity is protected by one FIDO key, which doesn’t exist until the entity is built on that endpoint. If, for example, you use 10 endpoints, there will be 10 different entities with 10 different keys so that the IdP knows exactly who the user is and what endpoint it uses. Because we let the endpoint verify, the user doesn’t have to do more than log into the endpoint. So, there’s no extra action needed for the user. No user local gesture and, for the endpoint, we can use the unshared key.

The company has enough central management capability to make sure the key is unshared. If the key is unshared, there are additional layers you can put on top of it so that, if there’s something wrong, you can know that too. In the case of the crypto apocalypse, in case of protocol failure, you have enough layers to make sure it is protected, or you know very early to protect against it. It’s future-proof with this idea.

Beyond FIDO of course is zero trust. Zero trust is something the entire world aspires to, and you all today as well, so we want to know more about that. But, if you look at zero trust, the aspiration of verifying user and device for all applications and for each transaction. Meaning, before you get an email, the server should check if the user is there. So, every minute the user should take the phone and press the button on the phone and so on. That is, as you all know, not possible. Now, because we use event-driven updates, the endpoint will tell the IdP if the user is not using it. It always verifies without continuous polling, without wasting any bandwidth. We also trust the endpoint because the endpoint can be protected with full disk encryption. No third party, no attacker, can go and manipulate the endpoint because it is fully protected. Zero trust is good, we just have to put event-driven updates to it.

The third best idea is, of course, the federated authentication so that the user doesn’t have to authenticate to each application. The whole world has always thought about authenticating users. So, we believe that we should have more provisions to take care of the endpoint. The endpoint focuses on federated authentication with SMAL, OIDC, and event-driven updates. For example, the application doesn’t have to check with the user: the application can always serve the user until the IdP tells the application to stop because the endpoint and the client are no longer available. With this innovation and new way of thinking, we can achieve that the user just unlocks the endpoint and all applications and services online can be done completely frictionless: completely no password, no MFA, no user action and no burden.

We propose, “endpoint access gives access to everything else securely.” We believe that, by having this new way of thinking, we can provide the most secure solution with the best possible user experience. The new way of thinking brings more than that. The power of it is, for example, the idea is you want to verify the user and endpoint. Traditional solutions, or even passwordless solutions today, in most of them, people verify the phone.

But, if you have verified the phone, the user has to do something on the phone and then somehow user vigilance is needed to have the binding between that verification into the endpoint, and that makes it not phishing resistant. The fact is that the MFA is not phishing resistant: they attack the user through human error on that. The solution is that we can make the endpoint the authentication device so no user action is required and it is completely phishing resistant. You can make the phone-based solution so much more phishing-resistant with users of vigilances. But, you can use it as a fallback so that, even if it requires more user action, it’s okay because you don’t use it every day. The fact that you have no action on online authentication makes the password reset or account recovery for you would become very rare.

The new way of thinking offers a more secure solution and even more. Let’s say, for example, we look at the Caesar MGM attack today the attack fooled the help desk: human error. So, it used the fallback and it let the help desk reset the MFA. If you use the endpoint as a main method and the phone as a phone fallback method, then you don’t need a help desk — there’s no human error to exploit. It’s even more: do you need the fallback? Today, everybody has a PC and a phone, like most people. If you don’t have a PC, you can use the phone. If you have a phone, you can use a PC to access online accounts. You don’t really need a fallback anymore. the fallback is only needed because most of the solutions make the endpoint, the PC, rely on the phone. If you don’t do that, then you don’t need a fallback anymore. There are many things which can go into the new way of thinking and that can change the entire cybersecurity space. Concretely, what does it all mean? For us, when we try to propose the passwordless journey for our customer, we very much differentiate between endpoint access and remote access. We ask, “Do you need OS login with MFA?” If you need, then you have Windows login, Linux login, and you have all the MFA with the phone biometrics, token, and PIV card, and so on.

If you want to be more secure, you want to have MFA for the pre-boot authentication for full disk encryption as well. MFA for pre-boot authentication with all these devices is available. It’s there, it’s just the entire world didn’t think too much about pre-boot authentication. But, WinMagic has provided that for 25 years. The next question is for online access: what application can support federated authentication? What application uses a username and password? How can you do so that, at the end, by default, your users don’t have to do anything because, as long as they have the endpoint access, they have access to everything else?

Of course, if the endpoint is unmanaged, it’s more difficult. We have to use the phone as most of the solution because the endpoint is unmanaged. But, as you all know, if you want the zero-trust principle, you have to verify the endpoint as well. So, it should rather be the managed endpoint and unmanaged endpoints are only used with not-so-sensitive applications. Actually, there is more to do. You see, even if you use federated authentication and all, there can be SAML — the golden SAML attack whereby the IdP is not trusted. Or, if for some reason you need a fallback method where you can use a FIDO token to go directly to the service provider without IdP, our solution offers the GPM as the endpoint software on the endpoint, the phone via Bluetooth as a FIDO key. Beyond the fallback authentication, you can use the FIDO as well.

I have been talking about user experience, but you know WinMagic is very security-focused. In the year 2000, we have certification from the NSA for secret and top-secret data for the US Government. We are the first one to get a Common Criteria certification in the world in 2002. We got the AES certificate, the first one from NIST, the certificate number one and we have provided continuous innovation in the last 25 years. As a result, we believe that, based on the endpoint capability and with all the conditions we can help implement zero trust faster with the best possible user experience.

At this point in time, I want to talk about our manifesto: the idea we would like you to look at and maybe comment on the speaker QA. It is probably thought-provoking. First off, we believe that it’s impossible to verify the user accurately. I mean, offline/online everything becomes data is very difficult to verify the user. But, even if it’s in person and you see the person in front of you, as we all know, you may think whoever it is, but you know from Mission Impossible that person may be Tom Cruise and nobody else. It’s impossible to verify the user. But, you can verify the endpoint 100% based on cryptography — based on public cryptography. It’s better to verify the endpoint the user uses and not the user and let the endpoint verify the user. That is what the whole world is moving into in the first place. The server cannot verify the user effectively. Let the endpoint verify the user.

In order to understand all this, to do all this, security practitioners — you — should differentiate between endpoint access and access to everything else because they are not the same. Endpoint access can give access to everything else. For endpoint access, you need MFA. For everything else, there’s no MFA and there’s no user action. Even more, people will always say you are the weakest link, but don’t take it. You are not the weakest link: the industry was wrong to put online authentication on humans in the first place. They should not. The next idea is that passkey is the right direction. Google, Apple, and Microsoft do that, that’s the right direction. Google’s test in 2017 showed that the FIDO key was 100% successful. Unlike other MFA, there’s no attack afterward.

But attacks are sophisticated. New attacks will emerge and you should understand what the right thinking is and what is the wrong thinking so that you implement the right thinking. Simplicity is the utmost sophistication. No user action is needed: that’s correct thinking, we believe. The market will converge, and we will see how far it goes. Also, there is a passkey and there is not so good passkey. Because, you see, sharing and saving the key on the server, if needed, may be needed. But, it can be compromised. I mean in the Solar Wind attack: even the most sensitive server key was compromised.

The next idea is about balancing workload. Who is in the best position to do what for cyber security?  For us we, believe that it’s very difficult for users to do online authentication. We do so that the endpoint can do it better. The endpoint does it and the user doesn’t have to do anything. But, when it comes to endpoint access,  it’s very difficult to verify users. The user, after logging in to the endpoint once, should lock the endpoint before leaving it unattended and that is what the user can do better than the endpoint — easier. Today technology doesn’t offer a 100% solution, that is given some workload to the user is correct. As we have said before, we focus on this. For example, on the endpoint, other solutions using the network the server AI, and so on are all needed. We have to work together to solve this very difficult problem, even though I believe that we’re going to do it very soon.

The endpoint is the one the users use to do everything IT. The endpoint can help the user the most about the user experience so that the user doesn’t have to do anything. The endpoint can continuously monitor endpoint-user intention and everything. This will deliver zero trust properly. We believe that, with the foundation of 100% accurate verification of the endpoint and the user, everything will become easier. I think I would like to show you one video.

Video Transcript:

Here the computer starts, and that pre-boot detects the user’s phone using Bluetooth. Once the phone is detected, the user will be prompted to authorize the login and complete the process using biometrics on their phone. Only a phone containing the correct key can access this device. This login can occur while the device is online and offline. From now on this phone can be used by the user to log into boot logon and Windows on this computer. Using single sign-on the user account is logged in, as is MagicEndpoint, and is available and ready for use. The user can start accessing online applications using no user action. Here the user opens Microsoft 365 and connects. Rather than the phone, this uses MagicEndpoint and SAML based authentication with no user action required.

Now, to demonstrate how the device trust signals work, we have created a policy that requires devices to be fully encrypted. If a device is not fully encrypted, the user will not be able to log into online applications on this device. To test, let’s log out of Microsoft 365 and start the decryption on this device. Now, because the endpoint is being decrypted, the policy takes effect immediately. When the user tries logging into Microsoft 365 again, they will be denied access. And, because the endpoint has a persistent connection with the MagicEndpoint Center, this event-driven action was detected.

 

Thi Nguyen-Huu:

You can have device trust in all. I have actually more to present. For example, about the idea of cryptography and endpoint, the idea of very strong authentication, and I’ll explain how we accurately verify the user and endpoint at the time of the transaction and is future proof. But, it’s probably too much for today, so you can have that in the PowerPoint presentation. We should have, now, time for question and answer.

Do we have any questions, Matt? I don’t see anything.

Matt Bromiley:

I apologize I was having an issue with my mute button here. Give me one second, I am checking in to see what’s going on here. All right we do have a few. So, I’m not sure if this is a question for you or more of an observation, but could one build an SSO solution that had MTLS or something beginning as the initial trust the endpoint step and do everything else the same?

Thi Nguyen-Huu:

I’m afraid I don’t understand the context yet.

Matt Bromiley:

All right no worries, I’ll see if I can get that person to throw a little more context out for us. The second question we’ve got here, for the FIDO Eazy, how many users per device are technically possible right now?

Thi Nguyen-Huu:

I would say unlimited. Let’s say you use a TPM, the TPM can support hundreds of users. Everybody will have a key that’s unshared and secure. If you use a phone, everybody will have their phone and we have a key on the phone which is also unshared. The endpoint would have unlimited user support and it’s bound to the Windows login — that’s the Windows user.

Matt Bromiley:

Yeah absolutely. All right, there’s another one that’s come through that talks about and it looks like I think it was right after the video was played. The question was, so this happen only with company-issued devices not with BOD trying to access corporate applications remotely?

Thi Nguyen-Huu:

Correct. Yes. Like we said, you have to have our agent on the endpoint to have no user action. It has to be a managed endpoint. For an unmanaged endpoint we have the phone, but then you use the phone like all the solutions: you don’t have the device trust signal, you don’t have any user action, you don’t have continuous verification and the monitoring zero trust would like you to have.

Matt Bromiley:

Gotcha okay excellent. Thi, there is a little bit more context on the MTLS question however it might be something that you might want to get into the Slack channel and look through. It’s a great question and I think it’s more about technical implementations and possibilities and things like that.

Thi Nguyen-Huu:

I will talk directly with Keith and ask more.

Matt Bromiley:

Keith thank you, by the way, for your questions you’ve been very active on a lot of the presentations today. But, I think it’s something that we’ll give Thi a moment just kind of look at it and then answer from a technical perspective. Another one that’s come through: can FIDO Eazy be run on an air-gapped environment for remote application authentication or perhaps a fingerprint authentication with it?

Thi Nguyen-Huu:

I would say yes. But, I want to verify again that, we can make it FIDO related, but we normally say fingerprint and MFA and so on should be rather used to unlock the endpoint. Once you unlock the endpoint, you can have access to everything else. Because the endpoint is your gate to everything else, it would be your self-driving car: your self-driving endpoint.

Matt Bromiley:

Right gotcha. Okay, excellent, awesome. All right, well Thi thank you so much and also I believe you came on a little bit early for us today as well so thank you so much for doing that and jumping in. It was great to have you here, awesome presentation, really great technical oversight and walk-through and there were a lot of compliments in the announcements, sorry, in the discussion channel. I highly recommend you check it out.

Thi Nguyen-Huu:

Thank you very much.

Matt Bromiley:

Thank you, Thi, I appreciate it, thank you.

Suggested Videos