Earlier this year, Teen Vogue wrote an article in its magazine about why their readers should adopt Two-factor (2FA) or Multi-factor Authentication (MFA) for any of their applications or accounts that offer it. Why is this relevant? Because according to the Verizon Data Breach Investigations report, 63% of data breaches start with cracked or stolen passwords. The fact that we are promoting and providing education around cyber-security to our teens today says a lot.
The benefits of having MFA enabled is that it provides an extra layer of security so that even if someone’s password has been stolen or they are using a weak password (either a reused password from a service that has been breached, or one that is very easy to guess), there is a second level of authentication required and a hacker won’t be able to gain access to whatever service, application or account being logged into.
For such reasons, regulated industries, like financial and insurance firms, are seeing increased pressure from regulators to enforce MFA on sensitive apps, with a timeline that is very compressed. And we also know that NIST will be preparing an updated draft to their Cybersecurity Framework in the near future which could include more around MFA.
Enterprises have already extended additional security authentication to web applications and this process is fairly straight forward, but to date have been slower to add it to other applications within the Enterprise. Even though IT security teams see the need, the general challenge has been that adding a second (or multi) factor authentication to applications traditionally requires development, testing, and ongoing maintenance. That does not include the cost or time it takes to complete such changes to applications. API integration and development work needs to be done for each application. And that development work isn’t done by the security team, meaning they have little control over it how long it will take and where it fits into the priority queue.
Now, multiply this out by the many applications in the enterprise, including legacy and home-grown apps and you can see the problem. And in some companies you may have more than one MFA offering, or may be planning to switch to a new MFA solution, which can further complicate things. A relatively large US bank has dozens of applications that still require integration of secure login capabilities. This is after multiple years of adapting MFA to internal apps.
Security teams need to look at innovative ways to approach this problem. Sticking with traditional access options exposes the enterprise and increases risk, including that of breach and lateral movement, until apps are updated to support MFA. Once a malicious “user” has acquired access to the network, they can find their way to other applications, data and resources, and could find access to more than they are allowed.
For security teams to quickly and easily expand MFA to sensitive applications at scale, they should look to add it to the network layer and turn the task of adding MFA support to applications into a matter of defining policy.
Vendor agnostic solutions can also provide the advantage of allowing customers to gain more value out of their existing investments in MFA solutions such as Okta MFA, SecureAuth, Duo, Google Authenticator and others.
Think about a scenario like this: When a user first connects to an application, the application attempts to verify the user’s identity. A modern network-based solution could proxy this request, and based on the policy, trigger the organization’s MFA solution to push a challenge to the end user. Once identity is verified, access to the application could be granted. Extending this type of approach to any application that authenticates over the network allows organizations to place consistent controls on applications regardless of whether they are hosted locally or in the cloud.
Having flexible polices allows staff to be able to fine-tune exactly how to enable secure authentication. For example, instead of forcing MFA for all users all the time, MFA could be required only for certain users or devices, or when a user connects from an unmanaged device. Likewise, MFA policies can trigger based on abnormal user behavior, such as a user connecting to a new asset, or from a new location or new device. This gives teams flexibility to apply contextual controls to any application, and keep end-users empowered while continuing to protect the network and its assets.
With the ability to flexibly and easily expand MFA at scale, Enterprises can reduce their risk of stolen credentials and potential breaches.
To solve this challenge, Preempt has recently announced Preempt Any App. Click here to learn more about this solution as well as how it can help with the ability detect and prevent threats in real-time.