I couldn’t be more pleased with Microsoft. On June 22, 2018, it announced a public preview of a new security policy which will enable multi-factor authentication (or MFA) for Azure Active Directory “privileged accounts” (or administrator accounts), including most Office 365 admin accounts. After the preview, they will automatically opt these accounts into the policy by default, adding a much needed layer of security to these accounts.
Why am I so pleased?
This is an important, proactive step by Microsoft to protect the credentials of administrator accounts that have “the keys to the kingdom” to their customers’ Office 365 environments. These accounts, if compromised, can be used by malicious actors to wreak havoc on an organization and their data, and, in the worst case, shut them down indefinitely. Their credentials must be protected at all costs.
Many 3rd party applications (including backup applications) that integrate with Office 365 and other SaaS products frequently require a customer to use application specific service accounts that aren’t tied to an actual user. And these accounts often need to have elevated, administrator permissions necessary to function correctly.
When vendors require service accounts to access Office 365, the added protection of Single Sign-On (SSO) and MFA can’t be utilized. This creates a dangerous combination: service accounts with elevated privileges and no additional protection like Multi-factor Authentication.
And to complicate the situation — this often means that the service account’s credentials must be stored by the 3rd party application to be used in the day-to-day functions. Even if credentials are stored securely and are encrypted when used by the application to authenticate, this still expands your organization’s attack surface in a big and dangerous way.
Now, if this isn’t setting off alarm bells in your head, it should be.
Here’s a good example of why. Late last year, Skyhigh Networks discovered a brute force attack specifically targeting Office 365 service accounts.
They explain: “The reason this is so clever is that system accounts, given their purpose, tend to have higher access and privileges than an average account. And, most importantly, such accounts do not yield well to authentication frameworks like Single-Sign-On (SSO) or Multi-Factor Authentication (MFA) and are also subject to lax password policies. These two aspects help reveal the motivation behind KnockKnock, (i.e. attack a weak-link with the potential for elevated exploits).”
You may be wondering, does this affect Spanning Backup for Office 365?
In short no, but let me provide some background.
Spanning has been backing up cloud native data in SaaS applications for several years. Spanning Backup for G Suite has been the leader for G Suite backup since 2012, and Spanning Backup for Salesforce was released in 2014. In all of our applications, we utilize an app-only authorization model (or OAuth 2.0), where an administrator provides a one time authorization to an application, giving it permissions necessary to function. Once the authorization occurs, the application functions independent of any user credentials —meaning the 3rd party application is unimpeded by a password change or MFA until the permissions are revoked.
When we built Spanning Backup for Office 365 in 2015, Microsoft didn’t have the capability to support this — so we worked with them to get it in place. It required much more work and complexity than relying upon service accounts, but it was the right thing to do — especially for our customers.
We made a conscious decision to support the security choices our customers have made when it comes to authentication. These security configurations are sometimes simple, sometimes complex, and are often unique to each customer. For example, many require multi-factor authentication across the board, or a single sign on application to ensure identity is managed properly, or both.
The great thing about OAuth 2.0 is that Spanning Backup falls back on the security configuration that customers have with Office 365 (or G Suite or Salesforce). And when industry standard protocols like this exist that enable 3rd party applications to work seamlessly and securely with SaaS products like Office 365, there’s no excuse to not use them. The customer should never have to make this kind of security tradeoff in order to use a 3rd party application — especially a data “protection” solution.
When I see a company like Microsoft making a hard decision like this to protect their customers’ business critical applications and data, they have my full support, personally and professionally in my role as the Senior Product Manager for Spanning Backup for Office 365. It’s one more step in the right direction toward securing all of our data that is stored in the cloud.
*** This is a Security Bloggers Network syndicated blog from Spanning authored by Andy Rouse. Read the original post at: https://spanning.com/blog/why-microsoft-requiring-multi-factor-authentication-for-privileged-accounts-is-a-good-thing/