On March 15, 2022, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) released an alert detailing a Russian cyberattack on a non-governmental organization (NGO). The threat actor chained together weak passwords, an inactive user account, default settings that privileged convenience over security, and a previous vulnerability in Windows. This enabled them with “access to cloud and email accounts for document exfiltration.”
In Part 1 of this series, RSA Global Cloud Identity Architect Ingo Schubert reviewed some of the best practices that RSA had shared with customers in the wake of this attack, discussing the purpose of multi-factor authentication (MFA), enrolling users in MFA, and how to minimize the use of passwords. In this second part of the series, Ingo reviews authentication resets, fail-safes and other scenarios that could lead to security incidents.
Let’s say you’ve completed enrollment. Moreover, you’ve followed our best practices and created enrollments that result in a high trust ceiling, allowing users to authenticate with a high degree of trust for as long as they use that authentication method.
Is our work done? Far from it. What about a user who loses or misplaces their authenticator? What about a user who gets a new smartphone and must re-install the app?
These scenarios will happen, and your organization needs to be prepared to deal with them in a secure and user-friendly fashion.
Does that sound familiar? It should. Your organization will likely replace authenticators in a manner that resembles their initial enrollment. At every stage, organizations must make sure they don’t open themselves up for attacks.
Don’t break the trust that you established during enrollment when replacing an authenticator. Remember: enrolling new devices, replacing enrolled devices and authentication resets are some of hackers’ favorite moments in the identity lifecycle. They incur a higher-than-usual degree of change, and as a result, represent some of the likeliest instances for attackers to gain unauthorized access.
Don’t let them. Look for a modern multi-factor authentication (MFA) solution that can secure these moments, offers API integrations into your identity and access management (IAM) and integrates your helpdesk operations all in one place.
Even if you did everything right during the enrollment phase and if you secured authentication replacement and emergency access, ask yourself: what good does that all do if you either don’t use MFA everywhere or if an attacker can simply switch it off and bypass it?
Resolving the first scenario is easy: use MFA everywhere (at least for the right users).
To do that successfully, your MFA solution should provide a variety of methods and interfaces to allow users to authenticate whenever and however they prefer. You also may need to check some legacy applications and can provide the right interfaces and ensure that they can utilize new authentication methods, such as FIDO-based passwordless or if you are stuck with good old RADIUS.
Let’s assume you’ve secured all your apps with MFA. You’ll also need to ensure that an attacker can’t switch MFA off. In the recent CISA alert, the NGO used an MFA solution that allowed users to log in without MFA if users couldn’t connect to the internet. The threat actor exploited that—it allowed them to effectively deactivate MFA just by turning off the connection to the internet.
Your organization’s MFA solution must therefore fail-safe and/or have an offline failover-fail mode that ensures MFA is enforced even if the MFA backend (cloud or on-premises) cannot be reached.
I understand the thinking when it comes to fail-open: to keep the business going, it’s better to allow logins with only a password instead of locking everybody out.
Understandable as that choice may be, it builds significant vulnerabilities into your security posture. The better—and safer—approach is to ensure that strong authentication works even if the MFA backend is unavailable. Whether your MFA backend is cloud-based or on-premises shouldn’t matter: authentication providers should provide offline solutions that work for both.
Securing offline MFA authentication is something we encounter frequently. Typically, we advise businesses to provide different methods for authenticating depending on whether a user is on- or offline. For instance, if a notebook is online, then the login into Microsoft Windows is secured using push notifications or biometrics. If the notebook is offline, One-Time Password (OTP) is enforced.
Because OTP isn’t as user-friendly, in this scenario we sacrificed some convenience for greater security. Doing so ensures that there’s no fail-open and that an attacker can’t switch off MFA.
Fail-safe behavior is not only important for an individual user’s Windows PC: it must also apply to all your on-premises applications.
What if the MFA cloud service you use is offline? That can and will happen. Maybe the MFA provider has an outage, maybe your internet connection is down. Maybe an attacker manipulated your DNS service in a way that makes the MFA cloud service appear to be offline: regardless of the situation, planning fail-safe/failover behavior can help your organization maintain business continuity and security even when your users can’t connect to the internet.
A hybrid on-premises/cloud high-availability MFA setup will save the day. Normally your applications will talk to the on-premises MFA component, which will in turn forward requests to the MFA cloud service. If the MFA cloud becomes unavailable, then all applications talking to the on-premises MFA service failover component will still be able to strongly authenticate users.
As with the Windows PC scenario, in this use case, offline authentication will be conducted via OTP only because push notifications to users’ smartphones will be unavailable given an internet outage. If there is a choice to enforce OTPs in case of MFA cloud outages or default to fail-open, then I’d pick OTPs 10 out of 10 times.
Properly configuring MFA from the outset, thinking through enrollment and eliminating fail-open MFA are some of the best ways to prepare for all these scenarios.
Another essential component is developing a governance practice that helps your security team gain visibility into identities throughout their lifecycles.
SecurID Governance & Lifecycle ensures that user accounts and entitlements are up to date. As authorization decisions—including MFA enrolments—will be based on identity data, it is critical that this data is reliable.
Something I haven’t touched on is Identity Confidence Scoring: SecurID can evaluate the trust in a user’s current MFA transaction based on their current context and past behavior. Identity Confidence Scoring is something we have been doing now for almost two decades. It figures into the SecurID risk engine and risk-based analysis.
SecurID supports all these best practices: from securing initial enrollment to resetting authentications to deploying hybrid authentication to managing identity governance, we’ve built on our decades of experience in designing smart, simple and secure solutions.
Whether you’re online or offline, whether you’re on-prem or in the cloud, there’s a way for you and your team to stay safe. Let us show you how.
