DEV Community

Cover image for Trust but verify
Kinga
Kinga

Posted on • Updated on

Trust but verify

Full trust solutions in Zero Trust Architecture

When assessing security risks associated with use of malicious SPFx, it's crucial to evaluate both the impact and probability of potential threats.

The financial and reputational impact is undeniably high.

And the probability?

There's not such a thing anymore as a potential attack or a potential threat. They're either threats that have been deployed and exploited or are sitting in your backend waiting to be deployed and exploited. by Elizabeth Stephens, CISO Workshop videos | Threat Environment and Trends

This combination of high impact and high probability elevates the risk to a critical level.

Certainly, this doesn't mean that all SPFx solutions should be removed from your environment. Users prioritize productivity, and if essential tools are blocked, they may find ways to bypass security measures to accomplish their tasks.

Your security strategy should focus on enabling secure work practices while maintaining a balance between productivity and security risks.

Routine part of IT process: review SPFx apps and granted API Permissions

Conduct regular reviews of installed extensions, the permissions they request, and those granted to the SharePoint Online Client Extensibility principal. Remove any unused solutions and revoke permissions that are no longer necessary.

Manual review

To simplify the review process, you may use the Export-SPFxApiPermissions.ps1 script, which generates Excel file with two reports:

  • summary of all SPFx extensions installed in SPO sites, including site URL, solution name and all API permissions declared in the manifest.

report 1 preview

  • summary of API permissions assigned to the "SharePoint Online Client Extensibility Web Application Principal", including SPFx solutions that requested them.

report 2 preview
It also displays a warning if any API permissions are assigned using Application mode, which is unsupported.

When using the script, keep in mind that a site-level app catalog, from a security perspective, functions like a regular list within a SharePoint Online site. This means that Global or SharePoint administrators do NOT have automatic access. Running the script as an administrator without first granting at least read access to the site would result in INCOMPLETE data. If the current user does not have access rights to a site hosting site-level app catalog, this script grants them Admin rights for the duration of script execution. The permissions are removed as soon as API Permissions are exported.

Automatic cleanup

Instead of manually review and delete unused permissions, you may decide to execute the cleanup process automatically, on a schedule.

Use the Cleanup-APIPermissions.ps1 script as a source for your Azure Runbook to regularly clean up API permissions assigned to the SharePoint service principal.
Use the -Interactive flag to run the script locally as a signed in user, or with -WhatIf flag to see what would happen without actually making changes.

Remember to assign permissions to the Managed Identity used by our automation. You may use the Grant-APIPermissions_ManagedIdentity.ps1 script that is configured to grant minimum required permissions to Microsoft Graph and selected SharePoint sites.

Enabling the site-level app catalog does require SharePoint Administrator permissions. This presents a good opportunity to engage with site owners on security practices and to obtain their agreement for regular audits of the SPFx apps they install.

Review the traffic generated by your SharePoint sites

In an era where external calls are common and often necessary, especially with the rise of reality-augmented generation (RAG) technologies, distinguishing between malicious and legitimate code or external API calls becomes challenging. The difference lies solely in the intentions behind the code.

One thing you can do to detect data exfiltration is monitoring and tracking API calls executed within any SharePoint Online (SPO) site. This can be achieved using the SPFx Application Customizer (PR to the https://github.com/pnp/sp-dev-fx-webparts repo pending) deployed tenant-wide to all SPO sites, that tracks all API requests and sends them to Application Insights. This solution allows whitelisting "safe" endpoints with a goal of reducing the amount of data logged. Additionally, it allows for temporarily disabling logging to facilitate randomized "hunting" without continuously generating large volumes of data.

Results can be reviewed using the Application Map in Application Insights or by executing KUSTO query against the Application Insights logs, offering powerful tools for analyzing and understanding API usage patterns.

Application map

For a more proactive approach, you may set up an alert automatically triggers when a new external API call is detected. This mechanism allows you to stay informed whenever an unfamiliar API request occurs. If the alert conditions are met, an email notification will be sent to designated administrators or security personnel.

Alert rule with KUSTO query

This proactive approach ensures that potential threats or unauthorized activities are quickly identified, allowing for prompt investigation and response before any damage can occur.

If the suggestion of downloading a SharePoint solution from a Git repository gave you a pause, we are on a good track. 😊

No need to worry. The PnP Samples do not include pre-built solution packages. Instead, you'll need to download the code and build the solution package yourself. This allows you to review the code and ensure that the package you install matches the code you've inspected. If you're not a developer, consider having your development team or a trusted third-party company review and build the component for you.

[UPDATE 26.08.2024: "Automatic cleanup" section added]

Top comments (0)