On March 15, 2022, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released an alert detailing a Russian cyberattack on a non-governmental organization (NGO).
The Russian actor used a brute-force password-guessing attack to compromise an inactive NGO user account. The threat actor was then able to enroll a new device with the NGO’s multi-factor authentication (MFA) provider, using the compromised account. By then exploiting the “fail open” settings, the threat actor was effectively able to switch off MFA by disconnecting their device from the internet.
Ultimately, the threat actor chained together weak passwords, an inactive user account, default settings that privileged convenience over security, and a previous Windows vulnerability. This enabled them with “access to cloud and email accounts for document exfiltration,” per CISA.
This blog post is not about bashing another provider. I have been with RSA for almost 20 years. In that time, I’ve experienced my share of cybersecurity highs and lows firsthand. So let me tell you: schadenfreude helps exactly no one.
What I will do is detail some of the advice RSA has given to customers in the wake of CISA’s recent alert. I’ll also explain how this advice applies to all MFA solutions.
Minor spoiler alert: every single feature or requirement mentioned in the rest of this article is part of RSA.
MFA is much more than an authentication method
To prevent attacks like this, organizations need to re-consider what MFA is, how users should initially enroll in MFA and how they’ll maintain those enrolments over users’ lifecycles.
Always keep in mind that MFA isn’t just about having a One-Time Password (OTP) token, authentication app, or a FIDO stick to log in. If you think you are secure just because you or your users happen to use biometric authentication on a smartphone to log into a cloud application, then I have bad news for you: that’s not MFA.
That’s only the bare minimum. Yes, it would allow you to tick the “Use MFA” checkbox for your compliance audit, but from a security perspective, this would be a waste of time and money.
Most authenticators rely on some cryptographic seed or key to authenticate. Hardware authenticators typically provide a higher level of security because they protect that seed to a greater degree than software-based authenticators. Businesses need to understand their security needs and pick an authenticator that provides good enough security—either hardware- or software-based authenticators can meet individual requirements.
However, the method itself—whether hardware or software—is almost irrelevant if the enrollment of the authenticators fails to establish adequate trust. Even if your organization is using the very best authenticators, if you manage them the wrong way, then they are next to useless in preventing or slowing an attack. Think of a car: just because you put a powerful engine into it and paint the brake pads yellow, that doesn’t mean you’re suddenly behind the wheel of a race car. You’ll also need to change your brakes, suspension, tires—and train the driver on how to compete in a real race. There is so much more to consider.
By reviewing a typical identity lifecycle, I will explain how to get the most out of an MFA solution and ensure that it performs the job for which it was intended: protecting your users and securing your digital assets.
Enrolment is the first phase in the identity lifecycle: during enrolment, an authenticator is assigned to an identity (a user). But even before an organization enrolls a specific user, it should consider a couple of questions:
- Who can enroll into MFA?
- How can a user enroll into MFA?
You may think the first question has an easy answer: everybody should use MFA!
However, there may be users or groups that should not or must not enroll. Think about accounts that exist but are not active—like an employee on parental leave, or orphaned accounts that were never or are no longer assigned to a specific user. A security team shouldn’t allow those accounts to enroll in MFA because any new or changed authenticator enrolments issued to these accounts are unlikely to get noticed. For example, notification emails noting changed settings will just sit there in some unmonitored inbox.
The second question is more crucial because it needs to be addressed from two perspectives:
- How can your organization’s enrolment reach the desired trust level?
- How can enrollment meet the desired trust level in a convenient and efficient way for both the user and the administration/helpdesk?
Any trust in an authenticator is determined by how it was initially enrolled: the degree of security a user has at enrollment sets their trust ceiling for as long as that user continues using that authenticator.
Another way of putting it: whether you’re using hardware or software, authenticators can only provide the level of trust needed for an MFA login or step-up authentication if the initial enrolment was strong enough. If you lay a shaky foundation, then your house will always be unstable.
There are a lot of ways to decide who can enroll and how they should complete the process in a way that balances both security and convenience. But whatever your organization decides on, make sure that you’re not だけ using passwords to enroll.
Why not? Passwords are convenient. The users already know their credentials, so the administrators don’t have to worry about anything other than pointing the MFA solution to an Active Directory. Right?
Wrong. While that’s an easy way to complete MFA enrollment, using only passwords leaves your organization open to all kinds of attacks. The worst-case scenario is that an attacker had already compromised an account and then enrolls that account in MFA. Enrolling an account in MFA that shouldn’t be enrolled in MFA is effectively the same as bypassing MFA altogether.
That’s exactly what happened in the successful attack on the NGO mentioned at the very beginning of this post. While there were additional steps that the attacker used to elevate their access, the enrollment itself was the fatal flaw.
There are smarter and safer ways to enroll authenticators. SecurID strongly advises organizations to layer additional technical and procedural controls around MFA enrollment. In fact, password-only enrollment isn’t possible by default in SecurID. A customer would need to go out of their way to enable that type of enrollment—and we’d be advising them against it every step of the way.
Determining appropriate enrollment depends on the authenticators that are available, the required trust levels, the capabilities of an organization’s MFA solution and the tools and procedures available to the company.
There are many technical controls that can help secure and simplify the enrollment process without resorting to passwords. For instance, organizations could:
- Rely on an SMS or Voice-OTP to a pre-registered phone number before enrollment
- Require users to contact the help desk to get an enrollment code
- Distribute an enrollment code to the user by email
- Print and share PIN letters to force users to use that unique PIN to enroll
- Assign and send hardware tokens to users (in this scenario, organizations should keep the tokens deactivated and let the user call the helpdesk to enable the hardware token)
- Allow enrollment only from within the company network
Of course, there are more controls available and various combinations are also possible. Organizations with large and diverse user populations should probably consider offering more than one way to enroll, which might result in different trust levels depending on the role of the user.
All these controls add security layers around the enrolment service itself. And although establishing these layers takes effort to set up and maintain, that investment has a huge payoff: authenticators that can be trusted.
But that’s just the first step in securing a user’s identity lifecycle. There are many more scenarios that prevent threat actors with significant opportunities and many more situations for which organizations should prepare. In the next part of this series, we’ll review resets, fail-safes, and other points in the identity lifecycle that organizations should prioritize to protect themselves and their teams.
