Overview
Traditional passwords haven’t been sufficient for protecting accounts and assets for some time now. From simple brute force attacks to spear phishing and pharming threat adversaries continue to develop novel methods for credential theft to add to their toolbox of existing tried and true approaches. Microsoft’s Group Program manager for Identity Security and protection, Alex Weinert, has previously stated that MFA, when deployed properly, can end up blocking 99.9% of automated attacks.
That sounds great right? The key though is ensuring that we not only deploy MFA soundly from a technical standpoint, but also that we back it with the proper policies, training, and processes to report, investigate, and respond to anomalous or malicious MFA attempts. In short, MFA can’t just be a technology we deploy to check a box.
More than a feeling checkbox
While most organizations fully recognize the importance of MFA, many forego the training, processes, and policies that should go hand in hand with a well implemented solution. As a consultant I’ve been called into assist companies that have deployed MFA on their own after a security event asking “Why didn’t MFA help us here?!” In most cases audit logs show that MFA worked exactly as designed, the affected employee simply approved a malicious request without stopping to consider the validity or source.
When we deploy MFA solutions, comprehensive training must be rolled out alongside the tech. When being challenged for MFA, team members need to stop and ask themselves, “Did I just take an action that would normally trigger an MFA prompt?” If the answer is no, or I’m not sure, there must be a policy to notify Information security for additional review. If security determines that the request is malicious, or the user is actively being targeted by an adversary, a pre-defined playbook should be followed to protect the account. Appropriate actions can include username or password rotation, beefing up a conditional access policy, additional education, as well enhanced monitoring.
Picking strong authentication methods
When evaluating MFA policies, it’s important to pick strong factors of authentication. If you haven’t looked into passwordless yet you should, not only can passwordless be an extremely strong authentication factor, it can also reduce employee downtime due to account lockout, as well as making associate accounts harder to phish. That being said, not all industry and compliance standards support passwordless as acceptable options (PCI DSS I’m looking at you here) especially in those cases picking strong MFA methods is even more important. Personally, I prefer methods that require you to enter information from one system/device to another. The best option available through Azure AD MFA right now is number matching with enhanced notifications. This is a relatively new offering that was rolled out into GA last summer.
As you can see above, the Authenticator app on my phone is displaying context data about the login requesting MFA. I can see the username, the SSO application being logged into as well as location data. Location data is provided by GPS chip if the device signing in equipped with one, otherwise location is based off the devices public IP address. Number matching can be used both for an MFA method, or combined with a biometric gesture and enabled for passwordless phone login using MS authenticator. This, or SMS verification are superior methods that make it much harder to inadvertently approve a malicious MFA request as you have to be able to see the screens of both the target and validation devices in order to satisfy the request. Phone or other “tap to approve” methods do not provide the same level of safeguard. FIDO2 or Hardware OTP tokens with rolling codes can also be excellent options.
For additional information on how Microsoft ranks sign-in methods, see the chart below. MS has also released into public preview the ability to use sign-in strength in conditional access policies to restrict access applications containing sensitive or confidential data to logins that meet a certain threshold of login security.