Making the Most of Microsoft Licensing to Secure Your Environment- Part 2

By Kevin Dillaway on March 29, 2022

In this multi-part blog, we will help walk through the best ways to take on the challenges around successfully implementing your M365 licensing while increasing your ability to secure the environment. Challenges include how to plan for the integration of the M365 product suite with existing processes to maximize the investment in the licensing that was purchased and being able to manage the amount of change that the M365 adoption can bring in a consumable way.

While Part 1 was focused on tackling the foundational components of tenant configuration, this post will focus on Identity and will get into the tactical components of the Microsoft capabilities that will be leveraged to secure, add visibility to, and move towards a zero-trust strategy for Identity. Identity and the next blog’s topic of data protection are the fundamental keys in not only securing your Microsoft cloud environments, but your entire corporate environment including mobile devices, unmanaged devices, and external connections.

Tackling Identity - Identity and Access Management

Identity has always been one of the single most important components of security, but one that has often taken a backseat to traditional components like networking or infrastructure to help provide a barrier to gain access to corporate information. With the data moving to cloud-based solutions like Office 365, the traditional infrastructure and networking protection is not as effective because access to the information only requires a connection to the internet. This is made even more precarious due to many SaaS applications, like Office 365, being designed to work best by being directly accessed from the internet and not being routed through network tunnels or proxies.

To help combat this, identity is on the front lines of security for cloud applications and platforms. Without a strong identity strategy for cloud, any SaaS application is vulnerable to a bad actor. The good news is if you have Microsoft 365 E5 licensing, many of the capabilities required to start securing identities are at your fingertips. These include:

Password Policies
Self Service Password Reset (SSPR)
Multi-Factor Authentication (MFA)
User and Sign-in Risk Policies
Conditional Access Policies
Application Consent
Entitlement Packages
Access Reviews
Role Based Access Control (RBAC)
Privileged Identity Management (PIM)
External Guest Control

If you have Microsoft 365 E3, then a subset of the capabilities above will be provided, but you will still have enough to get started in better securing identities for Office 365 and other cloud platforms. In the following sections, we will go into the details around how to leverage the capabilities above. The general order that they should be tackled will also be outlined based on the order that they are presented below.

Passwords and SSPR

The password has long been the weakest point in the armor we form to protect our companies. The recommendations around passwords have also changed significantly in the last 10 years from relying on longer complex passwords that should change at least every 90 days, to having shorter complex passwords that may never expire. The latter is only advisable if you have implemented additional “password less” technologies. By pairing the new solutions that rely on things like biometrics, facial recognition, or hardware tokens, the password becomes more of a last resort for logging in.

Even if you are proceeding down the path of password less authentication, Spyglass recommends that passwords be configured in a way that meets existing corporate standards while maintaining a good level of security practice including:

Requiring complexity
Generation and enforcement of banned password lists configured in Azure AD

This should be combined with the following:

SSPR
- SSPR allows for not only a better user experience, but also offers better security by automating the validation of users through multiple forms of verification when a reset is required
- This can also be paired with other Identity protection policies that would force the resetting of a user password when certain risk conditions were met.
Reduction of Identity Providers/Directories
- Having a single set of identities to manage not only simplifies management, but also increases security by having a single set of controls that can be used across all the identities. This also provides a deep level of visibility into user activity.
- SSO should be leveraged whenever possible to improve the overall experience.

Multi-Factor Authentication (MFA) and Conditional Access

MFA is now a mainstream control that most users will be familiar with based on the current interactions that they have with financial institutions and healthcare providers. MFA can significantly reduce the chances of a bad actor from compromising an account without overwhelming a user with controls. MFA adds the simplest control that can be layered on an existing password policy that can increase the cost for any bad actor attempting to breach an account or environment.

When MFA is paired with Conditional Access policies, the story gets even stronger. The use of the policies can allow for even better user experiences and make sure that MFA is being triggered when it is necessary. Normal factors that will come into play for Conditional Access and MFA will be:

If the user is inside or outside the company network
If the user is leveraging a personal or corporate managed device
If the user’s device is considered compliant
The application(s) that the user is accessing
The operating systems the user is accessing through
If the user is accessing over a web browser, thick client, or mobile application

Role Based Access Control (RBAC) and Privileged Identity Management (PIM)

At this point, we have hopefully a strong password policy that balances complexity without creating bad habits and users being prompted for MFA when it makes sense. Now, we need to tackle the much harder topic of only providing users with the permissions that they NEED. In the cloud, it is critical to make sure that we assign all permissions based on the principles of least privilege.

One of the biggest threats to every Office 365 tenant and cloud application in general is the over-permissioning of users and administrators. It is not uncommon for Spyglass to go into an environment and find 10+ users assigned the Global Admin rights. This is absolutely unacceptable when you realize that:

Most users do nothing that requires a global admin level of access
Global Admins only have a few permissions that are unique to them and can not be assigned at a lower level using other built-in roles

To come up with a true strategy to deal with over-permissioning, you must do the following:

Do an inventory of all employees that have elevated rights and:
- What they are doing
- How often they are doing it
- Where they are performing the actions (consoles, scripts, etc.)
From the inventory, determine what level of rights are actually NEEDED and how they vary from what is assigned
- Many users may require multiple roles to be assigned to achieve the full level of permissioning needed to do all aspects of their roles.
Implement PIM in a manner that allows users to request permissions when they need them
- This should require the use of MFA to get the rights
- For highly permissioned roles like Global Admins, the policy should also require justification and linking the work to a change ticket or incident.

No users should be given standing permissions outside of potentially a reader type role. It is also important to remember to go through the exercise across all applications and cloud platforms like Azure, AWS, and GCP.

Entitlements, Access Reviews, and External Users (Guests)

As we continue to layer on controls for users, the use of advanced capabilities like Entitlement Packages and Access Reviews needs to be addressed. This is often paired with how corporations deal with External Users and guests that need access to some corporate resources.

The access reviews will ensure that what people have access to is being reviewed so that access to any non-relevant resources is removed. This may also mean that a user themselves will be removed if they are no longer with the company, especially for external users and guests. The entitlement packages work well with the reviews in making sure that users (either internal or external) are only being provided with appropriate access to sites, applications, and other resources. These can be mostly automated as well based on group membership or other processes which again simplifies management while increasing the level of security by continually only permissioning people for what they need and reviewing that permissioning to make sure it is still relevant.

What is up next?

As we stated, this is just the first step. In this series, so far, we have covered how to start and also tackling identity. Over the next few posts, we will cover: