Enable Multi-Factor Authentication (MFA)
Greetings! We are publishing this blog post to continue our series for the re-vamped Microsoft Defender for Cloud Secure Score, and to educate the masses on the importance of Microsoft Defender for Cloud and what it can offer our customers…aka YOU. The desired result is to enhance everyone’s security footprint as much as possible leveraging one of the most (if not THE most) powerful forces of compute power on the planet.
What is Multi-Factor Authentication? I won’t go into too much detail here, but it’s basically a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cellphone or to provide a fingerprint scan. It leverages something you know (like a password) and something you have (phone / hardware key) or even leverage something you are (biometrics/facial scan). To read more about what MFA is and how it works, check out this article.
Before I dive into the subject of enabling Multi-Factor Authentication for accounts, I would like to address the WHY… Time to hop on the soap box…
We all have been told identity is the perimeter for defense. But what does that mean exactly? Back in the day you could get away with deploying network boundaries and relying on them to establish a good layer of network protection. Think of a moat around a castle as an analogy. However, over the last 20 years we’ve all seen/heard the news stories about how the “moat” approach failed (and continues to fail) time and time again.
To put things into perspective, there are over 300 million fraudulent sign-in attempts to our Azure cloud services every day. Think about the impact of that number on your own Azure tenant! The reality is that “Cyberattacks aren’t slowing down, and it’s worth noting that many attacks have been successful without the use of advanced technology. All it takes is one compromised credential or one legacy application to cause a data breach. This underscores how critical it is to ensure password security and strong authentication.” Reference - here…aka the WHY.
At Ignite 2019, it was discussed that out of all the Azure tenants globally, less than 8% of them WORLD-WIDE have enabled MFA. 99.9% of attacks on accounts are prevented by MFA. Question - Where does your Azure tenant fit in to the mix?
It’s very difficult not to go on a rampage verbally right now given the number of Azure tenants we have… so I’ll climb off the soap box instead.
OK so now you should have a better understanding of why addressing the security control “Enable MFA” is critical to the overall security of your Azure tenant, and in a lot of cases…your on-premises environments can be positively impacted too.
As you learned in this blog post (blog series), recommendations are grouped in Security Controls. This one control is probably considered one of the most important if not THE most important control to activate. Afterwards, your Secure Score will elevate 10 full points! I know it doesn’t sound like a lot, but with the new version of Secure Score it’s quite a positive impact, and is the largest number equated to a security control. Depending on your own tenant, it could be an 18% adjustment!
Note: For more information on Secure Score info, read this article here, and pay particular attention on how to ensure you’re getting the maximum points you can.
Also, the security control “Enable MFA” relates specifically to Azure MFA, not a 3rd party MFA provider. If you wanted to leverage a 3rd party MFA vendor, then we’d be addressing integrating one into an on-premises instance of ADFS in a Hybrid scenario. That’s not the topic of discussion and there’s plenty of available online references for that. Either way, MFA needs to be enabled regardless of whichever direction you choose for your organization.
Pertaining to licensing requirements, you can find all pertinent information regarding that here. There is a ‘free’ option to protect your tenant admin accounts, however it still comes with a cost. In order to take advantage of ‘free’ then you’re limited to either the global administrator accounts of your tenant…OR…your tenant’s got the “security defaults” turned on.
Without going into too much detail on “security defaults,” I will mention that if they are enabled on your tenant, the setting disables regular conditional access policies, then forces all users to have MFA after 14 days (amongst a few other enforcements). So be cognizant of that. Read up and learn more about “security defaults” here.
I believe all the main bases are covered in the blog opening so let’s get to the “meat and potatoes” of the topic at hand. Prior to doing anything, it’s important to make sure the environment is staged, set, and ready to go. Make sure you follow all the planning / recommended steps (found here) to ensure the MFA rollout is successful and issues are limited.
UPDATE TO POST:
We’re happy to announce that Microsoft Defender for Cloud now includes full support for security defaults, Microsoft’s free identity security protections.
Security defaults provide preconfigured identity security settings to defend your organization from common identity-related attacks. Security defaults already protecting more than 5 million tenants overall ; 50K tenants are also protected by Microsoft Defender for Cloud.
Microsoft Defender for Cloud now provides a security recommendation whenever it identifies an Azure subscription without security defaults enabled. Until now, Microsoft Defender for Cloud recommended enabling MFA using conditional access, which is part of the Azure Active Directory (AD) premium license. For customers using Azure AD free, we recommend enabling security defaults.
Our goal is to encourage more customers to secure their cloud environments with MFA, and mitigate one of the highest risks that is also the most impactful to their Microsoft Defender for Cloud secure score.
Security Controls
Let’s get going on the actual security controls now. Each one is actually a built-in policy definition contained within the Azure Portal.
MFA should be enabled on accounts with owner permissions on your subscription.
First up is the control under “Enable MFA” section in Microsoft Defender for Cloud Recommendations related to OWNER permissions for the subscription. This is to help enforce the control to prevent a breach of accounts or resources.
The last thing you want to do is allow some account that has complete ownership of your subscription to login without another factor of authentication. Simply letting a user account login with a password alone begs an attacker to compromise your tenant through a variety of attacks, taking full control of ALL accounts and ALL resources within the subscription.
Please…turn this on ASAP if it’s not already!!! You want to force MFA each and every time the subscription is accessed by an account with owner permissions.
MFA should be enabled on accounts with write permissions on your subscription.
Just like the previous mentioned control, this one too prevents a breach of accounts or resources on your subscription. Same methodology applies but the differences lie within permission levels. Even being able to write against a subscription allows an attacker to make unauthorized changes to accounts and resources without being an owner.
Again, I can’t stress enough the importance of enabling MFA and ensuring these controls are met!
On the path to Enabling MFA
There are a couple of ways to enable Azure MFA against your tenant. One way is to utilize conditional access policies, and the other is simply to turn it on against your user accounts. (Don’t forget about the caveat regarding “security defaults” mentioned above.) The screenshots show the latest GUI / portal interaction (as of the time of this blog post), but of course you can leverage PowerShell if you so choose.
Let’s look at the process for owner permissions.
Under the Microsoft Defender for Cloud Recommendations, simply click the link to initiate the process to enable MFA on owner permissions. It’ll take you to a subscription list page, then click the link associated with your subscription. Next, it’ll display the owner(s) of the subscription on the right side like this:
Click the continue button, and it redirects to the “conditional access policies” of the subscription.
Conditional Access Policy Method
Of the 2 methods mentioned previously, Microsoft recommends using conditional access policies (CAP) to enable MFA for users. Conditional Access policies enforce registration, requiring unregistered users to complete registration at first sign-in, an important security consideration. They give you the most flexibility and granularity when leveraging MFA in the environment. CAPs do require licensing of at least AAD P1, so keep that in mind. To begin your journey towards using CAPs and consuming gobs of relevant information, start here.
Given the flexibility and customization available for CAPs, the configurations could vary, so it’ll depend on what’s available for your tenant. Good news is that there’s “common” policy settings available for you to take advantage of that I’ll be addressing in this post. The common policies available are:
- Block legacy authentication*
- Require MFA for administrators*
- Require MFA for Azure management*
- Require MFA for all users*
- Risk-based Conditional Access (Requires Azure AD Premium P2)
- Require trusted location for MFA registration
- Block access by location
- Require compliant device
- Block access except specific apps
Regarding the ones with the asterisk * - if you enable all 4 that’s basically the same thing as doing the security defaults. Each link for the common policies above will take you directly to the article on how to set up and configure each one.
Reference Material - here.
Follow the above links for guides at enabling policies. At a bare minimum, Microsoft recommends you enabling MFA across administrative roles. Here’s an example of doing exactly that using the preview features (as of 7/2020):
- Sign in to the Azure portal as a global administrator, security administrator, or Conditional Access administrator.
- Browse to Azure Active Directory > Security > Conditional Access.
- Select New policy.
- Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
- Under Assignments, select Users and groups
- Under Include, select Directory roles and choose the following roles at a minimum:
- Authentication Administrator
- Billing administrator
- Conditional Access administrator
- Exchange administrator
- Global administrator (OWNER)
- Helpdesk administrator
- Password administrator
- Security administrator
- SharePoint administrator
- User administrator
- Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts.
- Under Include, select Directory roles and choose the following roles at a minimum:
- Under Cloud apps or actions > Include, select All cloud apps.
- Under Conditions > Client apps (Preview), set Configure to Yes. Click Done.
- Under Access controls > Grant, select Grant access, Require multi-factor authentication, and select Select.
- Confirm your settings and set Enable policy to On.
- Select Create to create to enable your policy. (PAY ATTENTION TO THE WARNING!)
Lastly, depending on the option selected below could impact your currently logged on account or not. Be mindful on your selection!
19 clicks of the mouse, and you’re done setting up MFA for administrative roles using the preview method of CAP as of 5/2020! You can see how customizable CAPs can be and just think of the flexibility you can leverage in your own environment. Just be careful you don’t accidentally lock yourself out!!
Direct User Method
If CAPs aren’t available to you at this time, then here’s a snippet of the process on simply enabling MFA against user accounts directly. Reference article.
Log into your Azure tenant (https://portal.azure.com), click Azure Active Directory, and go into Users, and then finally All Users. On the top menu bar, you’ll find “Multi-Factor Authentication.” Click it to open a new window to display the MFA user status.
Now that you’re on the MFA page for users, you can select all users who are OWNERS or WRITERS of the subscription, and roll out MFA in one fail swoop (Doing so for ALL users in the environment isn’t really recommended, you want to do that in chunks starting with the privileged accounts) or you can select individual accounts to start enabling MFA against for testing.
PRO TIP – Don't move users directly to the Enforced state. If you do so, non-browser-based apps stop working because the user hasn't gone through Azure Multi-Factor Authentication registration and obtained an app password. Only set them to Enforced after they’ve gone through the entire process.
Easy!
PRO TIP – Disabling MFA. We get a lot of customer questions that involve disabling MFA and the correct method to do that. Ultimately if you disable MFA at the subscription level…YOU MUST disable it at the management group as well or it won’t work!
This is the way you SHOULD be doing things: https://techcommunity.microsoft.com/t5/azure-security-center/centralized-policy-management-in-azure-...
Next Steps
Obviously, you should get working on getting MFA enabled! Get moving on increasing that Secure Score and preventing bad actors from taking advantage of this attack vector on your tenant! We hope to see the statics jump dramatically in the direction of more customers leveraging MFA for sure!
To wrap up this blog post, I’d like you all to keep in mind this is just a small fraction of what Microsoft Defender for Cloud and the Secure Score can offer our customers to drive their security posture through the roof. We’re just getting started and this basically translates into some robust steps you can leverage to increase your own comfort level in protecting your environments / assets.
I hope you enjoyed this article and learned something that will assist you in the continued fight of cyber-security. Please continue to enjoy our Microsoft Defender for Cloud Secure Score blog series and I look forward virtually seeing you all in the next one. Until then…
GET STARTED ON ENABLING MFA IN AZURE! :smiling_face_with_smiling_eyes:
Reviewer:
Yuri Diogenes, Senior PM CxE Microsoft Defender for Cloud Team