Protecting Users - with Intent

Ask anyone tasked with search engine optimization or user experience, and they will tell you that user intent is everything. While we leverage this data for many of our business decisions, we don’t use it enough for security.

We all know that current authentication and authorization processes are broken. We have bolted on security mechanisms like multi-factor authentication (MFA) and tried to assess behavior and other contextual information to provide additional protections for our users, but it obviously is not working. Also, many users do their best to avoid additional controls due to the complexity and inconvenience.

Tapping into User Intent

We need to rethink authentication and even some of our authorization decisions. Passwordless authentication is a good option for rethinking authentication. However, there may be a simpler option that is more intuitive for users. It starts with tapping into a user’s intentions.

If we knew exactly when a user planned on using their credentials, we could enable them for the minute or two they need to log in and then once they are granted a session, we can turn them off again. For most users this would mean they would only need to enable their username and password a few times a day at most. So, if we assume the user logs into an application 3 times a day and the authentication process takes an average of two minutes (which is being generous), then the user’s credentials would need to be active 6 minutes during that day or around 4% of the time. Which means that 96% of the time the credentials would be invalid.

If my credentials are only valid 6 minutes a day, how much less effective would brute force and password spraying attacks be for my account. If most of the other users are similarly disabled most of the time, would these attack techniques be worth the time and expense for threat actors?

Why Passwordless Alone Isn't enough

While passwordless authentication will also help solve these issues, I think it will be a long time before users are comfortable moving to passwordless as a primary authentication mechanism outside of maybe the mobile application space which is a more intuitive, seamless use case. However, all users are familiar with locking things up to keep them secure. Look at how many people locked their credit in response to the Credit breaches.

Extend this thinking to sensitive actions besides login, which in some cases happen much less frequently. For instance, I log into my bank once or twice a week, but probably only transfer money once or twice a month. I only transfer money to accounts that are not mine probably once every few months. What if, to perform an external transfer, I had to go to my local branch and tell them, “Hey, I am going to do an external transfer in a few minutes, can you unlock that for me?”. This would be much more secure, but also an extremely poor user experience.

What if, instead, I was able to securely update my status to “I plan on transferring money” and then have my bank securely check that status electronically before they allow the transfer to occur? If the user has agreed to set this status before transferring money to external accounts, this would authorize the bank to block the transfer if the status is not updated. If we can somehow get our customers to securely share their intentions with us, we can make much better decisions on their behalf.

How Next Level3 Improves on Passwordless

At Next Level3 (NL3), we provide a patented, API-first, JIT access, JIT Policy, PAM and JIT Approvals framework that allows applications to capture these intentions. For account login, users can keep their credentials locked until they need to log in. We can provide the same lock status or an alternate simple approval or even multi-approval process for other sensitive actions (e.g., wire transfers, large purchases, healthcare break-glass actions). For your corporate applications, we can also enable access for you to automatically update the lock status of users of your applications based on threats you are seeing in your environment. This allows you to quickly respond without having to go into individual applications to disable accounts.

In addition to capturing intent, users also get to see credential activity across all the accounts and actions they have setup within the NL3 service for connected applications, servers, or workstations. Users have the best context to be able to determine whether they just attempted to log in from a certain location or a certain device. Sure, the security operations center (SOC) may be able to do some correlation to determine this, but that process is complex and prone to both false negatives and false positives. Imagine how much more time our SOC analysts would have if they didn’t have to worry about login alerts.

How our JIT Identity solutions solve the problem

Next Level3’s JIT Access stands at the forefront of innovative MultiFactor Authentication (MFA) and Identity Verification technologies. By aligning with the revolutionary Zero Trust security principles, JIT Access combines advanced MFA techniques and biometric identification to provide a robust security shield for your AWS environments, remote devices, and medical devices.

This advanced approach safeguards against unauthorized intrusion and potential security breaches, helping to secure IoT devices and ensure the integrity of secure medical devices.

Attack Techniques – Mitre Attack Technique

Attack techniques (with Mitre Attack Technique reference) prevented or rendered less effective if NL3 status checks are implemented pre-authentication:

Gather Victim Identity Information: Credentials (T1589)
Username enumeration (T1589.001)
Brute Force (T1110)
Password Guessing (T1110.001) o Password Spraying (T1110.003)
Credential Stuffing (T1110.004)
Phishing (see explanation below – T1534, T1566)

For those keeping track, that is 1 of 3 techniques for gathering identity information and 3 of 4 techniques for validating or brute forcing credentials. The only other technique for brute forcing credentials requires offline access to credential information. For phishing, the protection would be limited to credentials or protected actions.

The initial attack may not be thwarted since the user may choose to unlock their account before providing credentials. However, if the attacker does not use the credentials immediately, there is a chance that the account will be locked by the time they try to leverage them.

Even if the attacker is successful in leveraging the phished credentials while they are unlocked, the user will be alerted of a login for which the details may not look legitimate. Also, after this initial access, if the attacker does not maintain the session, they will not be able to use the credentials to log in again if locked.

Furthermore, if the attacker uses the phished credentials to attempt to log into other applications, those logins will not be successful if the accounts are in a locked state and the user will get notified of the attempts.

While Next Level3 cannot stop certain relevant threats such as ransomware, malware, etc., the framework provides alerts directly to end users which may help the organizations discover these threats faster and reduces impact by preventing the use of discovered credentials and protecting sensitive actions. Protected actions can also significantly reduce insider threats. Especially when used with time-based or multi-approval policies.