Taking Power Platform Security and Governance from 0 to 60: Part 1

Introduction

Welcome to the first installment of my three-part blog series on securing low-code/no-code development within the Microsoft Power Platform ecosystem. As Zenity’s Director of Customer Success I’ve seen firsthand how businesses are embracing the power of applications like Power Apps, Power Automate, and Dynamics 365, all fortified by the impressive capabilities of generative AI. However, with great power comes great responsibility, and the challenges surrounding security are both significant and complex, and I wanted to provide an outline for how organizations can approach the unique challenges facing them as they seek to unleash and empower citizen development within Power Platform.

In this initial post, we’ll dive into how to kickstart a robust security program for your organization, addressing the urgent need to keep pace with the staggering volume and speed at which these apps and automations are being created, especially by non-technical business users (aka: citizen developers).

Understand What’s Sensitive and Non-Sensitive

Before you can effectively secure your low-code/no-code environment, it’s crucial to differentiate between sensitive and non-sensitive data and processes. Most admins will begin with separating the low-code platforms into distinct environments which have different purposes. Here, the main separation would be to differentiate between professional development and citizen development as we are talking about two distinct personas. On one hand, professional developers have some pre-existing security knowledge and training, and will likely be developing apps and automations which are widely adopted. On the other hand, citizen developers usually lack security knowledge, and will use low-code platforms to build apps and automations for personal productivity.

Organizations leveraging Power Platform should start by defining clear policies that classify data based on its sensitivity, and then apply appropriate controls and restrictions. Once we mapped this, security leaders need to make sure only allowed users/environment will be able to have access to business data and create apps and automations on top of it. This is where Data Loss Prevention (DLP) and configuring default settings play a pivotal role, but it also helps by establishing protocols and policies in place to determine which applications and automations that are created within Power Platform access, store, process, or otherwise interact with sensitive data.

However, be wary of common DLP bypasses that I’ve outlined in my prior blog series. This shows the need for dedicated resources to study and inventory all the different applications and automations that are created within Power Platform; as they will sometimes fall out of the purview of Microsoft governance; which is more focused on the underlying infrastructure, rather than the apps and automations created on top of their infrastructure. 

Next, configure your environment’s default settings to align with your organization’s security standards. This can include restricting external sharing, defining default data retention policies, and controlling access to critical resources.

Identify the Makers and Builders

The next natural step is to identify the individuals responsible for creating these applications and automations. These “makers” may be non-technical business users who just began leveraging capabilities within low-code platforms like Power Platform in order to accelerate their own productivity. Getting to know your makers is essential in understanding the potential security gaps. It is important to be aware that in Power Platform, every user is a maker, and without any approval they will be able to create resources like automations and applications in the default environment. 

Security leaders should continuously be engaging with low-code makers and builders to understand their objectives, what they typically build, and any common flaws or misconceptions they may have about security’s impact on their productivity. Collaborative discussions can help bridge the gap between their creativity and your security requirements. Establishing common trends for how certain people build different resources can allow security teams to pinpoint specific issues and work with business users to enable and empower them to build safer apps and automations, without hindering their productivity.

Implement Least Privilege Access

One of the fundamental principles of security is the principle of least privilege. In the context of low-code/no-code development, this means ensuring that users have only the permissions necessary to perform their tasks. Here are some areas to consider:

• What is the process for approving guest access?
• Which vendors should have access to which environment / resources?
• What type of access is approved?

After the organizational policies and frameworks have been agreed upon, implement robust authentication mechanisms, such as Multi-Factor Authentication (MFA), to ensure that only authorized individuals can access and modify applications and data. Security teams and platform administrators should also work together to review and limit implicit sharing settings, which can inadvertently expose sensitive data or functionality to unintended users. Explicitly define who has access to what, and regularly audit permissions.

One of the key and most common security risks with low-code development is overly shared resources. As applications and automations proliferate, it’s common for resources to be shared more broadly than necessary. Regularly assess and restrict access to resources to minimize the risk of data leaks or unauthorized modifications.

Conclusion

Securing low-code/no-code development within the Microsoft Power Platform, especially as it gains strength from generative AI, is a formidable challenge. However, it’s a challenge that must be met head-on to protect your organization’s data and operations. In this first installment of our series, we’ve laid the foundation for your security program: understanding data sensitivity, knowing your makers, and implementing least privilege access.

In the upcoming posts, we’ll delve deeper into specific security strategies and tools to fortify your low-code/no-code environment. Stay tuned for Part Two, where we’ll explore advanced security measures to further safeguard your organization’s digital assets.