Tough Love, Scared Straight

During our journeys with clients through security reviews of Microsoft 365 tenants, we’ve noticed some fairly concerning trends. So, bear with us while we don our dad-hat’s and commence with the tough love.

First off, multi-factor authentication (MFA) is still not being used by many of our clients in Microsoft 365 when authenticating to a tenant resource, whether that’s as an administrator or a user of an application or resource.

Adoption and integration of MFA is much better than it was even two years ago, but it’s still a passing subject for some institutions. So, let’s just put this to bed right here and now: MFA should be used in all authentication contexts if it’s available. MFA is not really a recommendation anymore. The FFIEC Architecture, Infrastructure, and Operations booklet supports its use, and the mindset of every IT security professional is that it should not be optional. MFA is an effective tool against abuse of phished credentials, including password cracking and spray attacks.

Yes, MFA is not always cost-free. Other considerations are the added cost of upgrades to Microsoft 365 subscriptions to support Azure Active Directory P1 or P2 (if not already implemented) and, depending on the features you intend to use, the potential addition of a third-party MFA vendor and licensing. If Azure AD is not used, there may be additional overhead of implementing and maintaining infrastructure to support Federated Services or management of accounts local to the 365 tenant.

We’d suggest that using the built-in Microsoft Authenticator app is generally the easiest way to go. And, like third-party authenticators, non-Microsoft accounts can be added to the Microsoft Authenticator app, given they support it. However, we understand that many institutions might already be using a third-party authenticator, and many of those also support Microsoft 365 authentication.

“Son, a man’s brand is his own special mark that says this is mine, leave it alone.
You hire out to a man, ride for his brand and protect it like it was your own.” — Red Steagall

Next up are legacy protocols. Microsoft supports legacy communications protocols like IMAP and POP for accessing mailboxes, and as of the time of this writing, these protocols are enabled by default; however, we highly recommend that you don’t use them, as IMAP and POP can both send credentials in the clear and do not support MFA by default. IMAP can support MFA using Modern Authentication protocols, but again, not by default. And what’s more fun than that, even if you do implement the global setting to disable IMAP and POP, this only applies to new mailboxes created after the global setting is applied. This means that you must go back and manually disable IMAP and POP—and any other unwanted protocol or function (like PowerShell Online and OWA).

Even after disabling the protocols, it is highly recommended that you test configuration changes. Even in Microsoft’s own documentation, they say those changes take time to take effect, and it’s our unfortunate second-hand experience that these changes might not take effect at all. Bullet points two (2) and five (5) in the following Microsoft Documentation link are very telling: https://learn.microsoft.com/en-us/exchange/troubleshoot/user-and-shared-mailboxes/delays-provision-mailbox-sync-changes.

Lastly, there is a market out there for Managed Service Providers (MSPs) that will migrate on-premises Exchange Server mailboxes to 365. They typically will do it quickly and will do it well, because mailbox migration isn’t really rocket science. They might also migrate other features, like email archiving, spam and virus filtering, email encryption, and backups. But, disturbingly, we frequently see where some MSPs seem to fall down is the application of security requirements and best practices.

Many MSPs are not as familiar with industry regulations and best-practice recommendations as one might expect, which can lead to serious security gaps. Thus, it behooves any institution to get an independent third-party security review of their 365 tenant to double-check MSP implementations, or your internal IT staff’s implementation, to ensure the implementation aligns with expectations. If you have in-house talent with knowledge of the subject and who is impartial to the migration project, then you may also perform this security review internally, but we find that’s pretty rare.

In conclusion, with legacy protocols enabled, the lack of some form of MFA for your Microsoft 365 tenant, sometimes careless or incomplete MSP implementations, and less-than-ideal access permissions, your customers’ data is ripe for the picking, which could also lead to the compromise of your tenant and on-premises infrastructure. And all it takes is successfully phished credentials from the weakest link: the user. We should know; we do it year-round in penetration testing and social engineering assessments.

Again, we realize that changes to infrastructure and managing new security best practices and expectations are not free, and neither are the security assessments. But all of that is a lot cheaper than the cost of damage to customers' finances and trust. Or rising insurance costs—of which some providers are now requiring attestation to the use of MFA—due to claims made on successful compromises of less-than-stellar IT security. Or reputational damage to the institution. Or regulators coming down on your institution with exam MRAs or MOUs, or the dreaded cease-and-desist potentially accompanied by the life-changing FDI Act 8(e).

Now, we’ll gladly step down from the soapbox. We want you to know we’ll ride for the brand. We care about you and your customers, and we’re here to help.

If there are any questions about the contents of this writing, or anything else, we have a talented pool of engineers, compliance experts, auditors, and operations and management staff ready to hear from you. We don’t want to have to talk about MFA again…or you’re grounded.

Thank you to Crissy Yates, Joann Lang, and especially David Bentley for contributing to this blog.

Authored by: Mike Smith, AWS CCP

  Download Blog