Power Apps - Security Review

Power Apps is LowCode, so its safe right, well no. If you dont believe me check out Hacked by a Power app, the truth is Power Apps have a lot of Power.

Power Apps should not be treated as cloud Excel/Access, and by that I mean spun up and shared with little insights. The use of connectors gives the developer high levels of access to your credentials, and the easy scalability/sharing of Power Apps makes it even more risky.

Would your organisation allow anyone to create a website that can access your emails, files, etc?

To ensure you protect your business (and the developer) security reviews are critical, along with:

• Archecture Reviews
• Design Reviews
• Code Reviews

One of the key strengths of the Power Platform is speed of delivery, and we don't want our security review to impact that. So key to this is patterns, patterns allow developers to follow pre approved designs, allowing solutions to meet secuirty requirements. Ive done a blog already on Power App Patterns here. Though from a security side often the way to create a pattern is to complete a full review on a live solution and then refine into a precident.

So what are the key areas of a security review should look at:

1. Data
2. Connectors
3. Access
4. Accounts
5. Sessions
6. Logs
7. Documentation

1. Data

At the heart of all security is data, securty risks levels collate directly with sensitivity of the data, once its above BI the security review will want to look closer.

Type
What is the heighest data classifiaction in the app,

BI - Business Information
PI - Personal Information
RPD - Resticted Personal Information
SPI - Sensitive Personal Information
CI - Confidential Information

What is the justification for the data, is the value worth the risk.

At rest
How is the data stored (is it encrypted or plane text), is it split across tables or all in one place.
Do the users of the app have full CRUD (Create Read Update Delete) permissions, what justification is there for those permissions? Can different parts of the data have different permissions? Who has full access to the data, why? how is access maintained (is there a process to review and remove access)?

In transit
How is the data encrypted in transit, does it pass through external companies, if so what are the legal agreements for the data. If data passes through flows are action input and outputs encrypted?

2. Connectors

Connectors give the App its power but thats the same power that can be misued. Apps often use on-behalf of permissions (the user's credentials) so there is potential risk there.

Number of
How many connectors are used, if the App uses multiple then there is bigger risk. E.g if the app uses SharePoint, OneDrive, Outlook and the App is hacked the hacker would be able to fully impersonate the user and have access to all of their data.

Permissions
Power Platform does not have granular permissions, you use Outlook connector to read their calendar you have permission to send emails. So the developer should explicity state which permissions and why.

Authentication
How are the connectors authenticating, ideally we want O'Auth, but some legacy sytems dont support it (or Power Platform doesn't support it). If we are using Basic or API key how is the password secured, how is access tracked?

Flows
Flows called by Apps are a higher risk because they can still leverage on-behalf of permissions, but run for upto 30 days. Again a justification as to why it is needed and why using on-behalf of permissions and not a service accounts.

3. Access

Securing the data of an app can go beyond simply authentiction, as this does not stop someone looking over your shoulder. A key consideration is conditional access, do you want to enforce MFA, geo-fencing or even on network (VPN). Microsoft has a conditional access policy in preview, its not 100% perfect but should be considered, else a way to enforce the conditions at the point of accessing the data.

4. Accounts

2 areas to look at here, the App owner and App users:

Service Accounts
The app and all related flows should be owned by a Service Account, this allows change control to be maintained. If its using the developers then they can access logs and update the App/Flow at anytime, and do what ever they want with those permissions.

Users
Access to the App should always be managed (try not to use Shared with everyone). The best way is Security Groups, here we can layer on approvals or dynamic rules. Dynamic rules are the best as this enforces removal of acccess when not needed. If its an approval then there needs to be a process to remove users who do not need access.

5. Sessions

Frustratingly there is not an out of the box session or inactivity timer for Canvas Apps (only Model Driven Apps), so as part of the review these timeouts should be considered. If there is no confidential data or inputs then it may not be required. But if there is any key requirment for access controls, session and inactivity controls should be put in place. With higher risk tighter timelines.

6. Logging

Logging of interactions is key for confidential data (tracking who access it helps data leaks) and can track updates to key data. Logging ideally is done in the app through Application Insights, or if lower risk can be done at the database level.

7. Documentation

We all hate it but a key part of a security review is documentation. Everything agreed and approved should be documented to help enforcement and future updates. The 3 key security documents are:

Simple Design Diagram
This covers all connections, users, access, data storage and data tranist.

Data and Classification
List of every field of data, with what classification and an example.

Acounts & Access
What service accounts are used, what access they have to each system consumed. Additionally what security groups are used for user access, how is it configured and how it is maintained.

A secuirty review should never stop a App, but what it should do is:

• Validate the risks/exposures are worth it, and encourage them to be removed if not necessary
• Inform the leadership, as if they want to take responsability and approve it, they need to understand what the potential outcomes could be and how likely.