Protecting extra-sensitive accounts and data sets in Microsoft 365, Part 2: Apps and DataAlex Fields
Last time we looked at some additional identity-based protections that are possible via additional subscriptions like Enterprise Mobility + Security E5 (which contains Azure AD Premium P2).
In this post, we’ll work within the same framework, but shift our focus from identity, towards protections which can be applied to apps and data.
Non-E5 Microsoft 365 plans already allow you to manually apply Sensitivity labels to your documents and messages, to protect them from unauthorized access and to apply permissions that restrict what various groups can and cannot do with a document (e.g. export/save as, print, etc.). But you can’t always count on users to do the right thing and label every sensitive bit and byte out there.
Automatic labeling is a feature of Azure Information Protection Plan 2, which will scan files and either “suggest” or just automatically apply the best label, without requiring an end-user’s input.
For example, you could add a condition like sensitive financial data (Credit Cards, ABA Routing numbers, etc.)–if this condition is met, apply (or suggest) the label.
Now this scenario I just described would only be triggered if the protected user opened a sensitive document in an app like Word, that was also outfitted with the Azure Information Protection client. However, when you integrate AIP with Microsoft Cloud App Security, you can find and protect data stored in cloud locations as well, even third-party locations such as Box (which can be connected to MCAS). Pretty cool, huh?
Advanced alert policies
Speaking of Microsoft Cloud App Security, this product also ingests activity logs from Office 365 and optionally other sources (e.g. firewalls, other cloud apps such as G-Suite or Box, etc.), and presents them in an easy-to-consume format, with an intuitive query building tool to boot.
It is hard to understate the depth of visibility this tool can give you into your environment, and it’s overall power in hardening your tenant. In fact, I call it the sleeper–the hidden gem–the understated star of the entire E5 suite of security offerings.
The pre-configured alerts alone are worth it; you will notice that MCAS can alert you to suspicious behaviors in your tenant, which is pretty huge on its own. I have to be real with you though: these alerts aren’t instantaneous.
It can take time for the logs to be ingested and interpreted by MCAS, so there is certainly a delay between when an activity takes place, and when you learn about it from this tool. Minutes in the best of circumstances, to hours in others. Still, the average time a compromised account goes unnoticed is 6+ months in most orgs, so this would be a massive improvement in any case.
Furthermore, you can create your own custom alert policies when there are parameters met that you would want to know about. Maybe you could ask MCAS to alert you anytime one of the protected admin accounts performs administrative actions, or even just logs in. Or maybe you only want to be alerted if the login is unusual like from a non-corporate IP address. When this happens, after it is discovered in MCAS, the account could be automatically suspended, or have all tokens revoked and the user would be required to sign-in again.
With all of these things in place, maybe you don’t care as much about “risk-based” Identity protection or PIM. After all, you could choose to mitigate the same risks in other ways, using this tool, instead of Azure AD Premium P2 (if you’re on a budget this license is only $3.50 USD / user / month).
Office 365 Advanced Threat Protection (Plan 1) is already included with both Microsoft 365 Business and Microsoft 365 E5 plans. E5 actually includes Plan 2, but the protection I’ll highlight here comes in Plan 1: the Anti-phishing policy, which allows you to select up to 60 users who can be protected against impersonation.
People often get confused by this protection, and I don’t blame them–it is confusing. The protection means that any individuals (internal or external) whom you name in the list will be flagged for extra attention against impersonation attempts. When a message appears to impersonate one of these named users, the desired action per the policy will be applied (e.g. Policy Tips, Quarantine, or whatever you have configured).
And, the user-based impersonation is going to be different than the domain-based protection because that part of the policy says “If it looks like someone is attempting to impersonate the domain, take action…”–not a specific user.
The key piece here to understand from a licensing perspective (and I think it helps illuminate how the policy actually works, too) is to realize that your list of up to 60 targeted users and domains to protect has nothing to do with the users who need to be licensed for Office 365 ATP. After all, even an outside email address or domain could be named here for the anti-impersonation protections.
The people who need to be licensed are the ones to whom the policy is actually applied. For Microsoft 365 Business users, I would apply the protections to everyone (since you are already licensed for it). And, I usually recommend the add-on across the board for E3 customers anyway (it is only 2.00 USD/user/month).
There are some other E5 security items, I am thinking specifically of Microsoft Defender ATP, that we just won’t get into–that’s a whole other topic of its own (a future Part 3 to this series could be “Endpoints”). In short, MDATP isn’t officially supported on Business plans–yet. I hear that may change in the future, but that day is not now. You could staple it on top of an E3 plan, though, for example via Microsoft 365 E5 Security for USD 12.00 / user / month.
Otherwise, as you can see here–we have many other tools in the tool belt, so to speak, that we can consider applying, if only to a small handful of extra-sensitive accounts. For the money, I would take a real hard look at Office 365 ATP and Microsoft Cloud App Security to start, and, if you’re like me and want access to the whole gamut, aim for one of the other big security bundles such as Enterprise Mobility + Security E5.
Now over time our options may change, as more features continue to trickle down from the Enterprise SKU’s and land in Microsoft 365 Business. I believe that trend will continue, and I am hopeful that Cloud App Security is one of those products next up (maybe even MDATP someday). Licensing is fluid, like most things in the cloud–and remember you can always change it later. As of today, these are my recommendations.
Hi Alex, I’ve just been told that someone was audited by MS for having a few EMS E5 licences which opened up full Cloud App Security and other AADP2 features, but because *all* their users benefitted from it, they were supposed to license all the users. This was from an MS partner during a licensing call we had with them.
Same goes for things like Office 365 Defender and AADP1 – we have some users that don’t need Office apps, so end up with a basic O365 E1 licence; some users are only for testing or services and don’t have a licence for Exchange etc at all, although we use them for signing in to things and would need conditional access and MFA to work on all accounts. We’re going to get them to help us get totally covered but I wasn’t totally sure they were right about some of this. I remembered that you had this and other articles where you mention securing just a few accounts using EMS E5 or E5 Security, but the way they described it, to comply properly you would have to adjust all your Cloud App Security rules to only apply to the licensed people (which sounds like a nightmare).
How does it really work when you have different levels of licensing? I know you can’t just buy one M365 E5 licence and open up AADP2 and all the clever security across the whole organisation for almost no charge – but nor does it make sense to want to secure 10% of your users with higher licences and be forced, in our case, to step back down from EMS E5 because we can’t afford to give it to everyone. Thanks.
That is correct, when you benefit from the feature you should be licensed for it. And if you have groups who do not benefit you should exclude those groups from any policies. For example, it is already a best practice to create security groups and manage license assignments via the groups, then if you were to create a CA policy that leverages AAD p2 features, you would use the corresponding group to target the accounts who are benefiting from that tier of licensing. That is the way.
That IS the way.
I’ve read a lot more about it as well now and I can see for example how to scope down to a particular group on Cloud App Security, as well as this useful page that details tenant-level services and how to ensure that you are targeting them properly (in case useful to anyone else reading this):
The partner made it sound like it was totally impossible/too much work to scope things to certain groups and that we should just move everyone wholesale to E3+E5Sec (a massive financial shock considering we’re a nonprofit with quite a few people on donated licences), whereas I still think our best option is as you describe – get into groups, add licences to groups, make sure everything is scoped, and we’re covered. I feel like it was a bit of a scareware tactic really, whereas here on your site I can see balance and a sensible way forward. Thanks again.