April showers bring May flowers… or so the saying goes. In the technology world, May brings us some very critical projects on deploying Multi-factor Authentication.
As we discussed in our April Project of the Month, remote work has been the central theme for over a year now, thanks to COVID-19. Not only are people working remotely, but they’re also generally relying on their digital devices more. Whether it’s ordering takeout from Skip the Dishes, getting groceries delivered from Save On Foods, or purchasing essential products not otherwise available in Canada through Amazon, people are creating online accounts just about everywhere.
In the business world, this is no different. More and more, a lot of organizations are relying on Cloud (SaaS) apps. From basic productivity apps (like Office 365) to CRMs (like Hubspot), just about everything has a separate login. While we always advocate for Single Sign On with a trusted Identity Provider (IdP), depending on licensing, or application capabilities, SSO isn’t always possible.
As a result, businesses need to protect an increased number of accounts. For May, we’ve seen an increased number of Multifactor Authentication (MFA) deployment requests, and we are highlighting it as our "May Project of the Month" because MFA is a critical piece of organization security.
What is MFA Anyway?
Imaging trying to renew your Passport without anyone checking your ID. That’s unthinkable. Unfortunately, in online identity, this is exactly what was happening.
MFA stands for Multifactor Authentication, which plainly speaking means requiring more than one piece of information in order to prove your online identity. Traditionally, that one piece of information has been the username/password pair. Usernames and Passwords are what are known as knowledge-based credentials. What this means is that both are something someone need to "know".
Typically, people tend to think of username/password like lock and key. But a more accurate analogy for passwords is a secret phase. Think back to those film noire spy movies, an agent knocks on a door in a dark alley. The man answers the door and says, “It sure is raining hard”, and the agent replies with “I always carry an umbrella.” Having given the correct question and answer pair, the agent is allowed inside. The agent never had to produce any physical proof of his identity. If someone had overheard this conversation, he could impersonate the agent without issue. You can see how this is incredibly insecure.
Imaging trying to renew your Passport without anyone checking your ID. That’s unthinkable. Unfortunately, in online identity, this is exactly what was happening.
How MFA Benefits Organizations
In May, our top project request has been deploying MFA for the very simple reason that it protects against a large majority of credential-based attacks.
This means if you have MFA enabled for all your staff, the majority of phishing attacks will be ineffective against your organization. This doesn’t mean you won’t have credential loss, but if you do, user accounts won’t be impacted.
With our clients, the biggest impact of MFA is when its deployment is coupled with a Single Sign On (SSO) implementation as well. Using Azure as an Identity Provider (IdP) secured by MFA for SSO means that organizations only have to secure one credential to harden the environment.
“Gotchas”
With any project, there are usually “gotchas”- things that sound great in practice but potentially create problems in reality.
User Education
One of the key learnings from our projects is user education around MFA. The less an organization prepares and educates its user base, the more we see an uptick in Help Desk support calls around MFA and general dissatisfaction with the feature. Because of this, we recommend organizations thoroughly prepare its user base when deploying MFA to avoid this issue. Fortunately, Microsoft has created MFA deployment user communication templates specifically to assist you in this endeavour.
Shared Accounts
Pay special attention in deploying MFA if your organization uses shared credentials extensively. Shared credentials are those username/password pairs that are known and used by more than one person. Generally speaking, shared credentials are a very bad idea for many reasons: it increases the attack surface (because multiple people may be the source of the breach), it destroys any audit capability (who actually did that thing if multiple people could’ve done the thing?), and it creates a nightmare for offboarding (do you change the password that everyone knows when one person leaves?). However, in reality, it is not always practical to not share credentials.
It is possible to share an account with MFA enabled, and we discussed it previously in Sharing Accounts Securely for Remote Teams. But care should be taken because of the additional complexity and training required for the end users.
Also consider user offboarding in these shared account scenarios too. When one person with access to the share account leaves the organization, the MFA device should be removed from access.
Have you deployed MFA? Is it on your road map? What’s holding you back? Let us know in the comments or chat with us on social media!
Comments