Hello everyone! I’m Yuval Adler, Customer Success Director at Zenity.

I’m inviting you to read my blog series where I share new Microsoft Power Platform DLP Bypass findings we uncovered.

Finding #1 – DLP Enforcement Failure on Existing Resources

This blog post is the first in a series explaining the new Microsoft Power Platform DLP Bypass findings the Zenity team has uncovered. This blog post focuses on Finding #1 – the problem with enforcing DLP policies for pre-existing resources.

Building low-code/no-code (LCNC) applications and automations continues  to soar in popularity in enterprise companies. Organizations are providing professional and citizen developers with the ability to accelerate development and quickly solve critical business use cases – for great positive impact in their company. In fact, according to Gartner, “by 2025, 70% of all application development will be done with low-code/no-code platforms, and 66% of large firms will be using at least four different low-code application building platforms.”

It’s an exciting democratization of app and automation creation – as long as employees can create without exposing their organizations to risk. When creating a security framework for LCNC, it is important to ground ourselves in existing application security best practices while realizing the challenges that make LCNC security unique and addressing them with dedicated solutions.As of today, most organizations lack ways to ensure that citizen developers are building software solutions that align with software security and governance standards such as OWASP Top 10. This is potentially extremely problematic, easily exposing an organization to data leakage.

One LCNC platform increasingly used by many enterprise companies is Microsoft’s Power Platform. It’s an intuitive, flexible platform that gives employees building applications and automations using Power Apps and Power Automate the option to use different services, connectors and data sources based on their business needs. Some of these might be external, third-party services and might even include some social networks. This is great for letting people customize their creations to their needs, but comes with security risks.

To try to protect the organization’s sensitive data and prevent users from potentially exposing organizational data, Microsoft came up with Power Platform’s data loss prevention (DLP) policies that define the consumer connectors that specific business data can be shared with.

Power Platform DLP policies enforce rules for which connectors can be used together by classifying connectors as either Business or Non-Business. If you put a connector in the Business group, it can only be used with other connectors from that group in any given app or flow. There’s a third category as well; sometimes you might want to block the usage of certain connectors altogether by classifying them as Blocked.It’s important, at this stage, to establish that these policies are not the same as what you may know as a data loss prevention (DLP) security solution, which focuses on detecting and preventing the loss, leakage or misuse of data through breaches, exfiltration transmissions and unauthorized use. By contrast, Power Platform DLP is more of an allow and block list.

DLP policies are created in the Power Platform admin center and they should affect any Power Platform canvas apps and Power Automate flows.

Although this is a great feature that can help organizations reduce risk, it covers only part of existing running resources and it’s vital that organizations be aware of those limitations.

Zenity’s research team has identified multiple flows and apps that have connectors configured to be “blocked” that are still active and running – completely breaking the organization’s DLP policy. We also found active and running data flows using both business connectors and non-business connectors.

A normal behavior we expected to see is with flows and apps using connectors that should be blocked, there might be a “suspended” or “quarantine” status.

The problem we’ve found is in the way the DLP enforces its policy on existing resources. Although they should have a retroactive effect on your applications and flows (see Microsoft Docs), in some cases, The DLP policies do not apply to existing resources. In those cases, the app or flow can easily bypass the DLP policies and will continue to run and access services the organization tried to block or restrict.

In the following screenshots from Power Platform Admin Center you can see the DLP policy “Approved connectors” (Screenshot 1) where the connector “MSN Weather” is configured to be blocked under the blocked connectors (Screenshot 2).

In the following screenshots you can see the flow “Button -> Get forecast for today” is using the connector MSN Weather (Screenshot 3).

From the flow’s maker perspective in Power Automate, you can see that the flow status is not suspended (Screenshot 4).

We were able to execute and run the flow. You can see in the following screenshot in Power Automate the execution time was Jan 16th at 11:33 AM and the status is on (Screenshot 5).

We also discovered that if you manually edit a flow or app it will trigger the DLP policy on existing resources (suspend or quarantine the resource), but practically speaking it’s simply impossible to go over thousands of apps and flows to check whether they’re compatible with the new DLP policy or not. 

To summarize, Power Platform DLP is a great feature, and it can act as a safety shield for your organization’s data. But organizations need to be realistic about the fact that it simply cannot promise full protection against unintentionally publishing proprietary data to audiences that shouldn’t have access to that data since it’s not fundamentally designed with security front and center.

In order to address these security risks, we’ve added dedicated rules to our security rules set to monitor for these specific scenarios and alert our customers every time an app/flow is bypassing their DLP policy and provide them with the ability to resolve this issue immediately.

To learn more about the security risks mentioned, feel free to reach out over email to yuvala@zenity.io. I’m happy to chat about this for hours.

The Zenity team is always looking for new ways to help our users protect their LCNC platforms. To continue, please check out the next post in this series, talking about HTTP calls.