The new SharePoint 2013 app model allows for some great opportunities to integrate externally hosted and/or developed apps that can be used to surface or send data into your SharePoint intranet, extranet or public facing web site.

However, this model also creates the opportunity for malicious code, trojan horses and other types of hacks into your enterprise.  Remember when Office started supporting macros – the feature was ultimately curtailed because it was EASY for end users to just one click install a virus incoming through email or through document attachments.  Even if an app isn’t technically malicious software, it could be considered a threat to our enterprise by end-users clicking on the magical “trust it” button and that app part being granted access to your sites, your lists, your documents, your profiles, etc.  While technically not malware, a marketing company could easily create an app part that displays a weather widget while burying in the fine print of the license that the person who installed it grants the company providing the widget access to their data for analytics, marketing or big data purposes.

How Apps are Granted Permissions

When an app is installed, it requests permissions through a manifest file packaged with the app:

As an example, I can write an app that requests Full Control over your site collection and if you click on the “Trust It” button, I now have full access to your entire site.

One of the key security mechanisms that Microsoft has done is to deny Full Control permission to any app coming through the Office Store.  However, this is not the case for apps that are installed through the corporate App Catalog.

How the New App Model Impacts Governance

SharePoint Governance is a huge concern for us at Navantis and we have a white paper posted on this blog introducing the principles of SharePoint governance here.

Microsoft has put together a really good article on planning for the new app model here.  Based on our experience doing security and governance audits, here are a few impacts to your governance strategy as you move to SharePoint 2013.

New Settings for Controlling Access to the Store

It is possible to turn off the ability to turn off access to the Office Store.  This can be done centrally as a method of lock down access across the entire farm.

Application Request Workflows for App Catalogue

For the App Catalogue, you can turn on the requirement to request and obtain approval to install an application by a site owner.  This is primarily driven by license requirements so that IT can manage who should have access to apps when these apps are licensed per user.  However, this same mechanism could be used for more general governance management purposes.

Limit Who has Full Control

At the minimum, a user must have the Manage Web site and Create Subsites permissions to install an app for SharePoint. By default, these permissions are available only to users who have the Full Control permission level or who are in the Site Owners group.

We have done many site audits where we find MANY users having Full Control when they don’t actually need it.  Here is yet another setting that will be inadvertently granted to site owners because they have been granted too much privilege because of the default “Site Owner” group.

Limit Site Collection and Tenant Administrators

In SharePoint 2013, there are two basic approaches for authorizing apps – either based on the current user’s permissions and/or based on the permissions granted to the app itself.  For example, in a user + app policy, an app that requests access to a document library or list will be thwarted if the current user doesn’t have access to that document library or list.  However, if the app is installed with an app only policy, then the app access is not constrained by the current user at all.

A user must be a site collection administrator to be able to grant use of the app-only policy. If the app-only policy is granted and the app already has tenant-scoped permissions, then the user must be a tenant administrator to be able to grant use of the app-only policy.

The Site Collection Administrator and/or Tenant Administrator roles should be limited and have the appropriate training and accountability as they could install an app that has vast access with no constraints by the user’s permissions.

Limit General Permissions to Least Privilege

As noted above, an app can be constrained by the permissions of the current user.  When an app is constrained by the user + app policy, the app only can access what the current user has authorization to access.

How many of your users have you inadvertently granted elevated permissions over a site or tree of sites?   While these users may not be malicious themselves, a badly behaving app could be and it could be piggy backing on these permissions.

Create an Auditing Strategy

Using a tool such as Axceler’s Control Point to audit your farm is a good idea especially when running a high security enterprise class portal.  With these new apps being able to access your data, this type of auditing becomes even more important.

It will be interesting to see whether these auditing tools can detect the distinction between me as a user accessing an object vs. an app acting under my credentials accessing a resource.  Being able to tell the difference might help detect bad apps instead of bad users.

This post was written by Chris Woodill
Christopher Woodill is the Vice President, Public Sector for Navantis. With over 15 years of experience planning, managing and implementing technology strategies in both the public and private sector, Christopher is responsible for public sector sales, strategy and delivery of solutions for our clients in healthcare, government, municipalities and education.