Cloud Native Organization Components
Context
In this scenario a representative Cloud Native Organization:
- May leverage Azure AD as a primary identity provider and for federation.
- May use different MFA controls, sometimes using smart phones with TOTP, push notifications, or SMS. Generally using multiple MFA providers such as Azure MFA, application specific MFA, or third-party solutions.
- May utilize SaaS applications for productivity (Microsoft 365), HR, scheduling, CRM, and other Line of Business Applications. Some of these applications are not federated with Azure AD.
- May have deployed custom web applications to the cloud that uniquely address their specific business requirements.
Enabling Strong Authentication
The Cloud Native Organization has a heavy reliance on Web Applications and needs to focus on securing the accounts accessing those web applications. According to Verizon's 2020 Data Breach Investigations Report, web applications are one of the leading Hacking vectors for breaches in almost every industry and vertical.
"2020 Verizon Data Breach Investigations Report.",Verizon, enterprise.verizon.com/resources/reports/dbir/. Figure 21.
While web applications were highly targeted, the report also states:
"Over 80% of breaches within Hacking involve Brute force or the Use of lost or stolen
credentials."
The evidence is clear that the best way to protect the organization is by protecting the user accounts.
Each component or resource in an organization may need to employ its own strategy to enable strong authentication and transition to passwordless. A Cloud Native Organization is uniquely positioned to take advantage of modern capabilities which are outlined in the following sections.
Enable phishing-resistant authentication methods
Microsoft has enabled capabilities in Microsoft 365, Windows, and Azure AD federated applications to allow for strong multi-factor credentials to be provided in the form of either a FIDO2 security key or a PIV-compatible smart card, both of which are supported by the YubiKey.
Deploying FIDO2 security keys is among the strongest MFA methods available to secure systems and applications. Enabling sign-in with security keys such as the YubiKey not only enhances security but also significantly reduces friction for the employee. The employees no longer need to remember username and password for any application that supports this credential. The YubiKey is now the credential.
Organizations should also investigate certificate-based authentication (CBA) with the PIV smart card application on YubiKey 5 series. While smart cards and certificate-based authentication have traditionally seen wider deployment on-premises, the rise of cloud-based certificate management systems (CMS) and recently released broad mobile device support for CBA has made it attractive for organizations that don’t have existing on-premises PKI infrastructure. CBA offers the same level of phishing-resistant security as FIDO2, but trades the self-service enrollment model of FIDO2 credentials for strong centralized issuance and credential management.
Both methods are supported simultaneously by the YubiKey 5 Series and Microsoft, enabling organizations to choose the authentication method best that fits their use case on a user-to-user basis.
If your organization has already federated your applications with your Azure AD tenant, the applications will now instantly be capable of phishing-resistant authentication. This includes Microsoft applications and services like Microsoft 365, thousands of SaaS applications in the Azure AD Application Gallery, and many other SaaS applications not registered in the Azure AD Application Gallery including your organization's own custom applications. The Microsoft 365 or Azure AD administrators simply need to enable this capability. Your organization's developers and application administrators do not have to modify their application to enable passwordless sign in if the application is already federated with Azure AD.
As you begin enabling phishing-resistant authentication in your organization, remember that users will have a tendency to use what they are familiar with. You will need to market and sell the features to the employees as it may be second nature to keep using passwords. Teach and encourage users to use passwordless sign-in with their YubiKeys. Show them how it will make sign-ins easier. Don't forget to remind them to register multiple keys to avoid lockouts and reduce support desk calls.
During the initial campaign to use passwordless, also encourage users at the same time to register the same YubiKeys as tokens for TOTP to support applications that may not yet support FIDO2 passwordless. Monitor the usage of phishing-resistant authentication as your campaign rolls through the organization. If you aren't seeing a significant adoption of users leveraging phishing-resistant authentication, then collect feedback from those user populations to understand why users are not adopting passwordless sign-in before you start requiring MFA.
Secure the admins by enforcing MFA
Azure AD Admins should protect their accounts with the strongest credentials and use FIDO2 hardware security keys or certificate-based authentication. This will provide them with the strongest credentials that are resistant to phishing, Man-In-The-Middle and remote attacks. It will also improve the user experience by providing them with the least friction during sign-in. This should be the first step to securing your environment and making sure all critical security controls and Azure AD services are protected. While custom Conditional Access Policies require Premium licenses, enabling MFA for Azure AD Admins can immediately be enabled with free security defaults that are offered to all Azure AD customers regardless if they have Premium licenses or not. As Information workers, Azure AD Admins will understand the need and be more likely to tolerate being the first to adopt a new phishing-resistant user experience when signing in for admin functions.
Drive more adoption of passwordless using Conditional Access Policies
Consider using Microsoft 365 as a first candidate for enabling MFA to drive adoption of passwordless sign-in across the organization. Email accounts and servers are an often targeted asset. This can be confirmed by the Verizon Data Breach Investigations Reports.
The 2020 DBIR mentions:
"Cloud breaches involved an email or web application server 73% of the time. Additionally, 77% of those cloud breaches also involved breached credentials."
The reasons to enable MFA for Microsoft 365 are clear, while at the same time, the conditions for enabling Microsoft 365 for phishing-resistant authentication are ideal. Microsoft 365 comes federated with Azure AD, it is a web browser based application suite, and is used by different departments.
If Microsoft 365 is not a good candidate for your organization to start a passwordless journey, the next best candidate should be a web based, high-value, highly visible Microsoft service or federated application where you can start driving mass adoption of passwordless sign-in using YubiKeys.
Start by requiring MFA for specific groups of users of Microsoft 365. You will be able to selectively choose which applications, groups, or scenarios by configuring Azure AD Conditional Access Policies. Conditional Access Policies allow you to apply fine-grained authentication policies based on a variety of static and dynamic signals. Organizations should resist applying a broad stroke policy that enables MFA for all users and every application. Review all the available signals in Conditional Access Policy configurations. Consider creating policies which require MFA for specific applications, and also create other policies leveraging Azure's risk engine and Identity Protection features to require MFA for risky sign-ins. By not requiring MFA for every sign-in, users will be less resistant to adopting MFA and which will simplify your MFA deployment.
Evaluate Conditional Access authentication strength
Currently in public preview, Microsoft has enhanced Conditional Access Policies to distinguish between the strengths of various authentication methods, allowing an extra degree of freedom to assign specific policies. Instead of simply requiring MFA, an organization can now ensure that phishing-resistant authentication is used for applications that require the highest security, while allowing a broader range of authentication methods in cases where security is less critical.
Microsoft currently has three built-in authentication strengths:
- MFA Strength, which includes all enabled MFA methods.
- Passwordless MFA Strength, which includes FIDO2, CBA, Windows Hello for Business and the Microsoft Authenticator App.
- Phishing-Resistant Strength, which only includes FIDO2, CBA and Windows Hello for Business.
Organizations can also define their own authentication strengths with more fine-grained control, like only allowing specific organization-approved FIDO2 devices. This allows organizations to restrict the use of FIDO2 authenticators to only those that are approved by the organization or have achieved 3rd party certifications like FIPS or CSPN.
Enable Windows sign-in with Certificate Based Authentication or FIDO2 security keys
In addition to web-based application sign-in, many users and organizations may want to leverage phishing-resistant machine sign-in using security keys that support FIDO2 or certificate-based authentication with smart cards. If appropriate for your organization's users, Windows devices can additionally be configured to allow sign-in using YubiKeys.
Not only will the passwordless sign-in make the desktop available to the user, all Azure AD federated web applications will leverage the same session for access. This eliminates the need for yet another sign-in when they access their organization's applications. This applies for both web and desktop applications such as Outlook that are taking advantage of modern authentication.
Federate your SaaS applications with Azure AD
Your organization likely has one or more SaaS applications that maintain its own identity store. Focus on centralizing all applications to use the same identity provider. By federating all applications with Azure AD, the sprawl of identity islands will be reduced, providing a single place of governance and control for identities' complete lifecycle. In addition to the central point of control, the users will have a single credential that is used for accessing all the federated applications. When users have many credentials to access their various applications, password management hygiene tends to degrade. By federating the SaaS applications, both the users and the organization will benefit while making passwordless for these applications an available option.
Azure AD has a large gallery of thousands of applications where all the work is done to facilitate the federation of commonly used applications. Applications that are not officially registered in the Azure AD Application Gallery can also be federated as long as they support one of the modern authentication protocols. Azure AD supports all the modern authentication protocols such as WS-Federation, SAML, and OpenID Connect. Most modern web applications will support one of these protocols making it easy to federate.
Evaluate mobile device and platform support for phishing-resistant authentication
Service providers and mobile device manufacturers have acknowledged the changing authentication landscape, and understand that in order to be competitive, their devices and platforms must support phishing-resistant authentication. This has led to recent developments in support for CBA on mobile devices, through support native to the device, or 3rd party applications that enable the use of phishing-resistant authentication mechanisms. This has led to an uneven but improving landscape for phishing-resistant authentication on mobile devices.
Organizations that have standardized on a mobile platform should evaluate the existing support for CBA and future support for FIDO2 on that platform in order to ensure that the broadest set of use cases will be supported on mobile.
Organizations that have embraced a bring-your-own-device approach will benefit from separate hardware authenticators like the YubiKey that are not embedded in a personal device, which will minimize or eliminate disruptions caused by device changes.
Enable alternate MFA options for applications that don't support phishing-resistant authentication
Until FIDO2 and CBA sign-in support is added across all applications and platforms, you will encounter scenarios where phishing-resistant authentication will not function. You might find lacking support from legacy applications, OS versions or browsers that haven't been upgraded yet. This will lead you to find alternate MFA options to secure your application until all the prerequisites can be met that are needed to support passwordless. For a Cloud Native Organization, MFA options are generally in the form of One Time Passcodes using SMS, or using an authenticator app to generate TOTP codes. While these common MFA solutions have well-known weaknesses, this is sometimes the best or the only available option. Microsoft published an interesting blog titled 'All your creds are belong to us' about MFA weaknesses, acknowledging which MFA solutions are susceptible to different attacks. As you encounter systems that won't support FIDO2 or certificate-based authentication, keep this information in mind and also keep it in context that an immediate short-term imperfect MFA solution may still reduce the likelihood of compromise to 0.1% of the general population.
Keep the long-term vision in mind. Evaluate solutions that will be familiar to your users and can later be easily migrated to a phishing-resistant solution when it is available. This can be done by leveraging the same investments in YubiKeys that you already made for enabling phishing-resistant authentication. In addition to the phishing-resistant FIDO2 and CBA capabilities, the YubiKey 5 series supports several other authentication protocols, including TOTP, HOTP and FIDO U2F on the same device.
Leveraging the one YubiKey to open up many doors provides a lot of flexibility, uniformity, and opportunity to start establishing behaviors in your users to use the same key to access all applications across all systems and devices. This prepares a more seamless transition for users towards phishing-resistant authentication while avoiding the need for additional licensing, support costs, software, and infrastructure. Consider the two following options:
- Enable Azure MFA OTP
Azure AD supports a variety of MFA options. One common option is to use TOTP tokens. The YubiKey can be set up to support Azure MFA requirements as a TOTP token. This will allow you to enable strong authentication for all the scenarios that won't support phishing-resistant MFA yet. Unlike other TOTP solutions leveraging a TOTP software authenticator app, the YubiKey TOTP solution stores the secure secrets in a crush and water resistant hardware key, and not in software living on a fragile mobile phone. This allows for a more portable and secure solution - allowing a single TOTP registration to work across all your devices and platforms. - Leverage non-federated SaaS Applications capabilities
Earlier we discussed the benefits of federating your SaaS applications with Azure AD. Inevitably there will be some applications that are unable to be federated for some technical, compliance or business reasons. Your enterprise should apply discipline and enforce all SaaS applications to be federated with your primary identity provider. If there is a legitimate policy or business reason for not federating the applications your organization should immediately secure the app with MFA. You may want to investigate the capabilities that are native to the SaaS application. Many SaaS applications will allow users to secure the sign-in using OTP codes generated by authenticator apps, or they might support FIDO2 WebAuthn, or FIDO U2F. For these solutions, your users can benefit from using the same YubiKeys that they are using for passwordless sign-in.
Summary
At this stage in the Cloud Native Organization's journey to phishing-resistance, they are beginning to gain traction and focusing on federating all possible SaaS applications with Azure AD so that they can leverage the investments that the big technology companies are making in FIDO2 and Certificate-based authentication. Today many of their applications and devices will support phishing-resistant authentication but support isn't everywhere. As the corners of the FIDO2 ecosystem become fully featured and gain support, this Cloud Native Organization will soon be ready to leverage phishing-resistant authentication everywhere. In the meantime, while they wait for that future to arrive, the organization is simultaneously securing their applications while beginning the transition. They put YubiKeys in the hands of their users so they can start using the same keys that are capable of phishing-resistant authentication and using the keys for TOTP, FIDO2 WebAuthn, and FIDO U2F MFA controls. The organization will soon begin to see less need for using the keys as OTP tokens and start seeing more and more use for FIDO2 or certificate-based authentication.
Continue reading the series with: Microsoft and Yubico Part 3 - Enterprise Strong Authentication for On-Premises and Cloud Organizations