Protecting extra-sensitive accounts and data sets in Microsoft 365, Part 1: Identity

As I have previously pointed out on this blog before, all of the best security products, like Microsoft Cloud App Security or Microsoft Defender Advanced Threat Protection, are held hostage in E5 plans. But there is a really big cost delta in the SMB space between the Business plan and Enterprise E5. And in fact, it is a fairly significant delta even moving from Enterprise E3 to E5.

I have two pieces of advice for you here:

1. Maximize what you can do within the subscription that you already have first (that’s already a lot)
2. Realize that you only need to license specific users for the “extra” features that are most important to you after that

For example, if any of your user base deals with really sensitive or even “toxic” data–the kind that would be very damaging to have exposed in a breach event–then there are some other things we could recommend adding to your bundle to help protect these special accounts and the digital assets those users work with. But you’d only have to license those users specifically for the add-ons that they need.

Licensing

In this post I’m going to highlight the security features that are normally locked up in E5, which could be bought separately and added to other subscriptions. However, my overall favorite combo for the SMB is:

Microsoft 365 Business (20.00 USD): Add Enterprise Mobility + Security E5 (14.80 USD) = 34.80 USD total

The idea is to create the best bundle which will contain the Cadillac of security features from the E5 plan, while remaining much more affordable. And again, you only have to apply it to those precious few accounts you care most about protecting. So it’s a nice middle ground.

NOTE: For E3 plans, you might consider looking at Microsoft 365 E5 Security and Microsoft 365 E5 Compliance; these plans are technically not compatible with Microsoft 365 Business, for example MDATP is not supported for use with the Business SKU at this time.

Before you start, identify the users who most need the extra protection. Be sure these users get licensed appropriately so they have all the necessary products enabled on their account. You will also want to create a security group for the purposes of applying additional features and policies.

Identity protection

Identity protection is a feature of Azure AD Premium P2 (9.00 USD / user / month), and uses risk-based conditional access to take action against login attempts that are deemed to be “riskier” than others. To determine risk level, Microsoft leverages signals from the Intelligent Security Graph in real time, and calculates whether the login behavior is safe and recognized, or unusual and likely to be an impostor.

You may need to add the Azure AD Identity Protection app to your Azure portal, first, if you don’t have it yet. Just go to the marketplace and search for it, then click Create to get started.

There are several “value-added” policies here that you can use to enhance the typical user protections, such as MFA, which are available in other subscriptions.

MFA registration policy – Require users to register for MFA, before actually issuing MFA challenges; when users are prompted to register, they can choose to bypass the registration for up to 14 days, but eventually they must complete the security info registration process. This will help ease people into the transition and let them accomplish registration at a time that is more convenient to them.

User risk policy – Probably the most important policy to configure, it can either block or require the targeted users to complete a self-service password reset whenever the user account is elevated to a certain risk level (MS recommends Medium risk as the threshold for most orgs to strike a balance between usability and security). Risk level can be elevated by risky sign-in activity, or other evidence (e.g. darkweb) that indicate the account could have been compromised.

NOTE: Similar protection is also provided now via a baseline Conditional access policy which is included with all subscriptions (however at this time it is not possible to make exceptions in that policy).

Sign-in risk policy – Stuff like impossible travel, unusual sign-in time, location or device, etc. can elevate risk level of any given sign-in attempt, and here you can choose to challenge sign-ins that are above your selected threshold with MFA; I personally don’t see as much value here and generally recommend simply requiring MFA at all times if the account is highly sensitive. Otherwise I would set this to Low risk and above.

Alerts and Weekly Digest – Get email notifications when suspicious looking stuff is happening in your tenant, right under your nose. You can also see who is being impacted by the risk policies you have in place.

Privileged Identity Management

Another Azure AD Premium P2 feature. You can find PIM under Azure AD > Identity Governance, but you may want to add a handy shortcut for it to your Azure portal view from “All services.”

What is PIM? Specifically useful for controlling access to “superuser” administrative roles, this technology will allow you to discover and then convert accounts that presently have administrative privileges, into accounts that are merely “eligible” for privileges.

By rescinding the admin rights up front, you are then able to setup an approval workflow, whereby an admin would request and be granted or denied access to privileged roles (only when necessary for making administrative changes). You should also setup email notifications so that you are alerted when these things are happening in the environment.

All that having been said, I know most of my SMB readers out there will have difficulty seeing how this applies to them. But in customer environments that are very sensitive to change and who put a big emphasis on security, this could be a very attractive offer: “Look, you will hold the keys to the kingdom–and we can only come in and flip settings around when you specifically ask for it, or approve our requests to change something in advance. And that also means attackers who gain unauthorized access will be similarly limited.“

Of course, this implies that you would want at least a couple of customer-enabled accounts who could approve requests for privilege elevation.

Next time

I only have one other article in this series planned at this time–so next we’ll talk about data and app protections that are available from the world of E5, and what it would take to add them to a down-level SKU like Microsoft 365 Business or E3. See you next time!