Conditional Access for Data: How Labels, Encryption, and DLP Should Mirror Identity Protection

Why data deserves the same conditional, contextual protection we perfected for identity.

In my last blog, I drew a mental connection between the way we often treat and view Multi-Factor Authentication and the principles that drive Its success to Microsoft Purview’s Purview Message Encryption and Rights Management enabled Sensitivity Labels rather lack of a similar approach, and how we should rethink this.

Now, this week, I’m expanding on this quite a lot - I found myself enjoying breaking down the fully fleshed out principles of Identity Protection (yet ever evolving) with the constant tinkering and figuring out we’re all doing with Data Security (and compliance, and governance, etc. etc.). So, if you’re still following on, I thank you, and please bear with me as I continue to unfurl the ideas I have around this - and hopefully it makes as much sense to you the reader as it does to me. So, let’s get into part 2 of my thesis linking Identity Protection and Data Protection.

“Everything that Conditional Access does for identity - classify, assess, restrict, adapt - Labels and DLP do for data.”

So, we’ve now designed and built out the Purview Advanced Message Encryption enabled sensitivity labels, our “MFA”, we need to start thinking about what this all means when we talk about protecting data in context. Microsoft’s Entra ID protection provides us with a very good roadmap for a very well planned out, adaptive, risk averse yet pragmatic data security journey - if you know where to look. Let’s zoom into Identity Protection and specifically Conditional Access; what are the core tenants of it?

1. Block legacy authentication

2. Require device compliance

3. Enforce MFA

4. Reduce session privileges

5. Block high-risk sign-ins

6. Require terms of use

7. Monitor sign-in context

These core tenants of a CA Policies are pretty clear and fleshed out by best practices allow organisations to control sessions and protect people and the applications or APIs that we need to work and add value to how we work, while, inherently protecting the environment and assets. A good CA Policy framework and implementation evaluates the risk, and if the conditions are good and meet what we’ve set out, grant access - while verifying explicitly. When we needed more than Multi-Factor Authentication, conditional access was created, and Microsoft solved the question of “Should this user, on this device, under this risk, be allowed to access this app?”, organisations often mature identity thinking a lot faster than data thinking and with an ever expanding data-verse, we attempt to answer the fundamental question “Should this data, with this sensitivity, under this context, be allowed to move or be used?”

Within Microsoft Purview, we have a wide range of very valuable tenants available to begin addressing the question. With Sensitivity Labelling, we get to apply rights-based permissions and encryption, and with Data Loss Prevention policies we get to set the conditions around how that data should be moved, where it’s allowed to be moved, where it can be stored, who gets to use it and how. The following are the main tenants we need to consider answering our burning question:

1. Block unlabelled/unencrypted data from leaving the organisation

2. Require classification before saving

3. Enforce encryption before sharing

4. Reduce rights to data (via permissions)

5. Block data from high-risk endpoints and users

6. Require justification for downgrading a label

7. Monitor content context and the movement and usage of data

By comparing the 2 tenants, I am trying to draw a clear alignment between the identity plane with the data plane - from “what condition should apply to this identity?” to “what condition should apply to this label/data asset?”. Placing this directly into a real-world frame, here’s an example that I will use to explain my point:

Identity Plane:
If a device is not compliance, CA restricts the session.

Data Plane:
If a document is labelled “Internal”, DLP restricts its ability to leave our organisation.

A statement I’ve always held near and dear is that Labels are not a security feature, but productivity-enablement with security built into it and belongs to the business. The “Internal” label, with its Full Tenant Encryption (assigning a permission only allowing people with @yourcompany.com access). With this, we are ensuring that the access to this document, email, SharePoint Site, Meeting, or PowerBI report is locked down to only the employees - we are explicitly verifying that access. Like a CA Policy that ensures that the device that users can log in from to access the organisation must be compliant - or that the user can verify their identity. I’ll add another example:

Identity Plane:
A user with high-risk sign-in gets blocked or challenged.

Data Plane:
A file containing highly sensitive project information gets blocked from upload or sharing.

Again, we are ensuring that there are mechanisms in place to ensure high-risk users, as well as high-risk data movement or access is controlled. There are both financial and legal liabilities that both examples hold if we do not think about them in similar fashion - defend, protect, verify.

The gap I’m attempting to bridge here is that with Conditional Access policies, we have all the right templates in place to address identity risk, but with data, we need to align the way we attempt to address the risks to it. To achieve this, an organisation needs to understand that encryption-enabled labels alone are not enough, they need DLP Label Policies, that dictate enforcement and building contextual conditions within each rule.

“For Identities, MFA was the beginning and Conditional Access was the evolution. For data, encryption is the beginning, and label-driven DLP is the evolution”

To tie all of this together, the scenario that plays out on the Identity plane is rather simple, right?

1. User signs in from home.

2. CA requires MFA

3. CA see the device is compliant

4. CA sees sign-risk is low

5. CA permits access

Now, on the data plane, with encrypted labels, the same scenario plays out.

1. User opens a labelled document.

2. Internal Label checks the user’s account for Full Tenant Encryption entitlement.

3. Rights are applied immediately - they are granted access.

That data trust plane has been established. Now, the user is actively interacting with the document, and we find them attempting to share it.

1. A label-context DLP policy for exchange checks what the label is and who the recipient is.

2. A toast notification is displayed instructing the user on proper sharing of Internal labelled assets.

3. The conditions are not met, and therefore the very sharing of the data is not compliant, and the sharing is blocked.

The data access and sharing were conditional throughout the user’s interaction with the labelled asset.

Zero trust is built on MFA and Conditional Access policies to protect an identity, to ensure that access is conditional, and with Data, the access to it was similarly conditional, with Labels and DLP controlling the consequences. Without an alignment of Zero Trust with data, it collapses within the organisation and has ripple effects that inevitably distorts trust. Zero Trust in this sense requires that we verify, validate, classify data, enforce policies based on context, and monitor risk-based behaviour towards data.

“We protected identity with conditional access, now we must protect data the same way”.

What’s Coming Next

In my next blog, I will expand a lot more from a sign-risk and the adaptive capabilities of CA policies with the equally capable user-risk and adaptive protection Microsoft Purview offers using Adaptive Protection and Insider Risk Management.

Acknowledgements

I want to thank Ray Reyes, Ewelina Paczkowska, and Ryan Perrin for their perspectives and contributions to Data Security and identity protection to shape this week’s reflections. Go follow their LinkedIn profiles some insightful and thought-enriching content!