Why Multi-Factor Authentication Should be at the Root of Your Security

Executive Summary

In October 2020, Unit 42 researchers published the 2H 2020 Cloud Threat Report, which centered around identity and access management (IAM) threats. Due to the significant impacts resulting from the Multi-factor Authentication (MFA) security vulnerabilities exposed within the Solarwinds breach as well as the recent MS Exchange vulnerabilities, researchers see a growing risk towards organizations using cloud environments which could allow for attackers to bypass Identity Provider (IdP) security tools.

Due to the high degree of trust organizations must place within their IAM and IdP configurations, researchers wanted to take this opportunity to provide a high-level overview of how IdP tools facilitate identity and authentication services towards cloud environments and what threats can be introduced if organizations fail to correctly configure that IdP tool within their cloud environments.

Identity Providers and Multi-Factor Authentication

Cloud-focused Identity Providers (IdP) such as Google Accounts and Azure AD are not the only identity providers available for cloud platform authentication; Okta, Auth0, SailPoint, and OneLogin are also common cloud-focused IdPs.

IdPs perform the critical function of authenticating user accounts and provide the critical first step in providing identity confirmation with an established Zero-Trust architecture. When the cloud platform and IdP have been configured properly, the IdP provides user or service account authentication, and even provides the security best-practice of Multi-Factor Authentication (MFA), prior to the account being granted access to the cloud environment and its resources.

Access to cloud resources is facilitated by the cloud platform itself and will provide the role-based access controls (RBAC) which effectively grant and limit a user or service account from performing actions or connecting to cloud services.

When a user or service requests access to a cloud resource, the IdP performs the authentication operation and if approved passes the request, along with which RBAC they are granted, to the cloud provider which then assigns the preconfigured identity and access management (IAM) Role or Group policy allowing access to cloud resources.

It is important to know that when an IdP is being used to manage authentication of a cloud environment, there are additional security steps required to ensure that a cloud environment remains secure, over and above ensuring that the IdP and cloud provider RBAC rules are inline. The following will highlight how an IdP tool and cloud platform should be set up (from a high-level) and what risk can be introduced if their integration is not properly configured.

The following image is a basic outline of how an IdP platform will integrate with a cloud platform.

1. User requests access to a particular cloud service.
2. The IdP verifies the user’s identity and contacts the cloud platform to initiate the RBAC rule configuration.
3. The user’s enterprise authentication directory confirms the user's cloud rights and privileges, the pre-created RBAC rule for the cloud environment.
4. A cloud platform then attaches the new user session to an IAM role.
5. The IAM Role is attached to an IAM Group or Trust Policy within the cloud provider and this allocates services to the user.
6. The user’s IAM role, via an IAM group or policy, is given access to the requested cloud service.
7. The user is allowed to access the requested cloud service using the new temporary account session.

As Figure 1 illustrates, the cloud provider is not responsible for managing the user authentication to the cloud environment, as this is now the responsibility of the IdP. As such, any MFA functionality required either through a compliance and governance framework will need to be configured through the IdP platform and not the cloud platform.

Additionally, auditing of the User’s account is no longer associated with the cloud platform. There may be some logging events recorded within the cloud platform, such as resource allocation and IAM roles being assigned to IAM groups or trust policies, but the vast majority of user events surrounding Auditing, Authentication, and Logging of user requests will be generated and stored within the IdP platform.

So where is the security risk? The risk is actually centered around the cloud provider’s original administrator account, the IAM Root account. This account is the first account to be created during the onboarding process. The root account holds all of the keys to the kingdom if you will, as it is the original account that starts each and every cloud action taken, and all of the cloud resource building and usage moving forward originates from this account. Since an organization’s cloud footprint initially begins with only this account, it is very powerful, and naturally is also targeted by attackers. Should this root account become compromised, an attacker would be able to masquerade as THE administrator and access any and all cloud resources including, VM, DB, serverless, or storage instances, IAM services, user accounts, roles, groups, or policies created by the organization, and any of the network infrastructure.

Since the root account is all-powerful, it is even capable of bypassing any IdP authentication frameworks put into place, since it would have been used to create the IdP connection in the first place. So, what are the defenses an organization can put in place to help protect the root account? MFA is clearly essential. Multi-Factor Authentication, also referred to as Two Factor Authentication (2FA), is the process of providing two, or more, forms of authentication before being granted access to an application.

The three forms of authentication are:

1. Something you know
   • A password or passphrase
2. Something you have
   • A token authentication platform, like a hardware security key, a software token application, or even an SMS token
3. Something you are
   • A biometric scan like an iris scan or voice authentication

If the root account does not have Multi-Factor Authentication enabled, and the attacker acquired the access ID and key for that root account, there would be nothing in the way to prevent an actor from accessing any component of the cloud account.

MFA configuration for root accounts is a critical stopgap measure in protecting cloud environments. Unfortunately, researchers found a 42% increase in the number of organizations not implementing Multi-Factor Authentication for root accounts within their AWS environments between October 2020 and the time of this writing.

Should these root accounts become leaked via GitHub or GitLab exposure, or should Root access be acquired through privilege escalation attacks, attackers would be able to circumvent any IdP platforms put in place.

When incorporating an IdP into the cloud architecture, the cloud's IAM Roles and Groups are required to play a much larger role within the management of user privileges and service safeguards. When a user requests access to a particular service, an equally restrictive IAM group must be assigned to that user’s IAM role before that service is accessible. If the IAM group grants privileges to more services than were requested, the security of the larger cloud environment may be compromised.

As can be seen in the figure above, if an attacker were to gain access to services higher in the cloud environment’s permission set the attacker could work their way to an administrator. Every effort should be made to limit overly permissive security roles or groups within cloud environments and efforts to enforce the principle of Zero-Trust, or the Least Privilege principle, should be strongly enforced.

Make Sure to Secure Root Accounts Now with Multi-Factor Authentication

Root accounts pose a critical security risk to cloud environments. Providing proper security protection for these accounts should be an urgent priority for any organization operating in the cloud. Since October 2020, researchers found a 42% increase in the number of organizations not implementing MFA for root accounts within their AWS environments. Organizations improperly configuring and maintaining their cloud environments could experience grave consequences.

Researchers strongly recommend that organizations limit operational functionality from the cloud root accounts to only the establishment and configuration of an IdP platform. The root account should then have MFA enabled, preferably via an MFA hardware token, and the root account should never be used, except for dire emergencies such as resetting the cloud environment itself. Any and all administrative functions must be performed through a newly designated IdP based administrative account.

Finally, the principle of Least-Privilege should be applied when creating and maintaining all IAM entities, be they users, roles, or group privileges. The critical misconfigurations discussed can be detected and alerted upon, out of the box, within Prisma Cloud. The platform allows organizations to maintain awareness of their cloud environment configurations, especially for those organizations using a multi-cloud setup.

Recommendations

• Ensure that the cloud environment root account has MFA enabled, preferably with a hardware token.
• Use the root account only to set up the IdP configuration and never use that root account for any other function.
• Create an IAM administrative account configured through the IdP to perform all administrative functions.
• Monitor IAM Roles, Groups, and Trust Policies through the Prisma Cloud’s IAM Module.
• Employ the principle of Least-Privilege when building IAM permissions.