In our previous blog introducing Continuous Threat Exposure management (CTEM) , we described CTEM as a mindset and process to quickly determine real risk in an organization’s attack surface, and equally as quickly address mitigation to reduce that risk.
Multi-factor authentication (MFA) is an authentication method in which a user is granted access to a resource only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism, from disparate sources such as knowledge (something only the user knows, for example a password or PIN), possession (something only the user has, such as a security token/USB stick or an ATM card), inherence (something only the user is, using a physical characteristic or biometric such as a fingerprint, face, voice, or iris, or pre-captured trait such as typing speed or cadence), or location (somewhere a user is, such as connected via a specific network or using a GPS signal to identify a location).
While MFA may not be the panacea for all access and account management risk, and one can argue that passwordless authentication is the wave of the future, there is no question that today MFA is a critical security control to reduce the risks of compromised passwords and account takeover attacks.
That is, if it really is working as intended.
Like every cybersecurity solution, if not properly implemented and configured, MFA can easily be beat, decreasing its effectiveness and becoming much more vulnerable to phishing, man-in-the-browser, and man-in-the-middle attacks. Many companies acquire expensive MFA solutions, go through extensive enablement phases, and then assume everything works.
Unfortunately, this is not always the case. “MFA Effectiveness” is an area of SecureSky’s exposure hunting that often elicits surprised response from our clients when first reviewed, because it uncovers risks in an area thought to be a fairly simple “set and forget” security control.
To manage risk from MFA solutions not doing their job, SecureSky regularly reviews areas such as:
MFA Policies, Rulesets, or Conditions
Dependent on the solution being used, the parameters of the solution might be called something different, but the dashboard of the tool should be reviewed to establish that policies for each defined category of user privilege and type of centrally controlled MFA (for example device, browser, or application) have not been deleted, are enabled, and have not been modified since an approved change management date, as well as certain timing and conditions to trigger re-authentication (for example, impossible travel or anomalous activity).
In Azure Active Directory (AAD) these types of policies are referred to as Conditional Access Policies, and a policy inventory as illustrated below:
Frequency of MFA Multi-Factor Authentications (Days Between)
Reviewing the days between MFA is an indication that policies are working as intended, for example all users are re-authenticated no greater than every 30 days, including users using the same devices and the same locations. The inverse of this is also true, as users not re-authenticating with the defined risk tolerance period is a strong indicator that there are conflicting policies enabled, or there are users not covered by the policy set.
Below is an overview example indicating such issues, with the ability to drill-down to analyze specific users and groups to remediate such conflicts or coverage gaps.
Days Since Last Login
This analysis can indicate two risk factors. The first being a signal that there are user accounts that require maintenance, meaning disabling dormant user or guest accounts.
The second is to identify “break glass” accounts, or accounts set up to bypass normal access controls in a critical emergency. While such accounts are a necessary evil, they must be regularly audited, because they typically are used for root systems and offer highly privileged access. Mandatory policies for break glass accounts includes a credentialing process, notification of access, and a time duration upon the credentials.
The below graphic is an example of an environment with a large exposure of stale or break glass accounts.
Authentication Type Trend
Authentication type is what technology or connection triggered an authentication, for example primary/SSO access, per-user MFA (typically configured to not trip as often when access is from a trusted IP address and/or device), additional tool/policy driven conditions, or by an application.
On a macros basis, this trending analysis is an indication of how policies are actually working, especially during phases when such policies are being expanded or tuned. An example of this type of trending is shown in below.
Multi-Factor Authentication Method
Authentication method is “how” a person provides an additional identification factor, beyond their initial credentials, for example by acknowledgment or receipt of a code via text or phone call on or to a registered or known device, biometrics on a known device (such as Windows Hello for Business), use of a physical security key, or connection to an authenticator application registered to the user, such as Microsoft or Google Authenticator, Duo Mobile, or Authy, again with an acceptance process or by the application generating a time-limited OATH verification code.
Each method has its pros and cons, balancing risk with user convenience. This is a particularly important analysis, again, to understand that the MFA methods the organization wishes to use are being utilized.
This analysis should be segmented by type of user group/access, with more stringent methods being used as privileges increase.
An example of this analysis shows the percentages by method of authentication method. The below environment indicates a user environment primarily using text messaging, or SMS as labeled in the above chart. While below this specific method there are multiple sub-methods, for example texts requesting simple yes/no user validation, adding geo-based intelligence, or even number matching from an additional data source, the below analysis would trigger additional research given simple text messaging's susceptibility to social engineering. The recent "MFA bombing" (also known as "MFA fatigue") attack on Uber, in which the user was tricked into pressing "yes" [meaning, yes, this authentication request was really made by the user] by an overload of push notifications lacking additional context or interaction requirements is a prime example of the weaknesses of this authentication method.
Summary
Each graphical example included above is a macro or high-level representation of the data. The tools used by SecureSky allow quick mining and drill-down of the data to identify the root cause of gaps in policy or account coverage. Additional areas of authentication and identity management exposure hunting performed by SecureSky not represented in this overview include non-interactive sign-ins, guest users, and detailed Conditional Access analysis.
MFA Effectiveness Analysis is just one example of exposure hunting performed by SecureSky on a regular basis to verify that critical security controls are operating as intended. Other areas of exposure hunting include applications, service principals, storage, threat detection policies, and cost control. For further discussion on how to incorporate exposure hunting and management and continuous attack surface reduction into your security program, please do not hesitate to contact us by clicking on the links below.
If you have any questions related to multi-factor authentication or exposure management, please feel free to contact us by completing our contact form or emailing info@securesky.com.