The SharePoint Folder Permissions Security Fallacy

By Kurt A. Mueffelmann

Everyone managing a SharePoint environment knows they must keep sensitive data from falling into the wrong hands.

However, most set permissions at the folder level, applying strict permissions with the expectations that employees will follow the rules and put sensitive documents in the right folders to keep files out of the wrong hands.

There might not be one silver bullet for securing SharePoint, but the idea that folder permissions are in any way the answer to SharePoint security is a fallacy. In fact, administrators need to think beyond the folder and down to the document level to ensure security, using metadata as the key to making it work. 

The (Flawed) Folder Permissions Security Reasoning

The bare-bones explanation of how folder permissions can secure a SharePoint environment goes something like this:

SharePoint administrators can create folder permissions with the aim of making sure that only employees with the appropriate authorization have access to folders containing sensitive information.

For instance, if a company is storing employees’ social security numbers in a SharePoint folder, the SharePoint administrator can create permissions that only allow certain HR employees folder access.

These permissions ensure that any document placed inside this folder will automatically be secured because of the folder’s permissions.

Keeping this social security example in mind, SharePoint administrators can apply different permissions to all sorts of folders, and train employees to file their documents appropriately in each folder.

Folder permissions, coupled with strong governance rules and employee training programs that stress the importance of putting sensitive files in the appropriate folders, go a long way toward keeping sensitive documents out of the wrong hands.

Where Folder Security Breaks Down

At face value, it seems like folder permissions can secure, if not contribute to the security of SharePoint.

But SharePoint is a platform for collaboration, and SharePoint’s social nature inevitably destroys an administrator’s ability to secure sensitive documents at the folder level.

Even if a user initially puts a document into a secure folder, there's a strong likelihood that he or she will copy the document to other folders when collaborating with different users.

As folder structures become increasingly complex and contributors are no longer sure what files go where, they stop using SharePoint and go back to what they feel comfortable with – putting all documents into the top folder, then copying the materials they need to the desktop or another library.

Treating SharePoint like a filing system with locks on different folders only works as long as everyone always puts the files back in the right folder.

Regardless of the amount of employee governance training, it’s all but inevitable that SharePoint users will copy and share files.

Once sensitive files are placed in folders that do not have the appropriate permissions, the SharePoint environment is no longer secure.

If Not Folder Permissions, Then What?

In order to secure SharePoint and prevent human error from causing data leaks, SharePoint administrators must look at document-level security strategies.

Unlike folder-level permissions, document-level permissions travel with documents regardless of where they are in a SharePoint environment.

In other words, document-level permissions allow individual pieces of content to remain secure from employees and SharePoint administrators alike, regardless of whether these documents are stored in the appropriate folders.  

SharePoint administrators can put in place a slew of other document-level security measures that can't be done at the folder level.

For instance, administrators can set up systems where documents are automatically classified based on the presence of sensitive information. Administrators can also create permissions that prevent documents from being printed, edited, or saved outside of the SharePoint environment.

Still, some SharePoint administrators reject the idea that document-level security is a sound approach on the basis that SharePoint’s out-of-the-box features don't allow for document-level security.

Document-level security requires that SharePoint administrators define security policies against the appropriate metadata, and SharePoint out-of-the-box has limited metadata functionality.

For instance, administrators can't prevent people from accidentally or maliciously editing document metadata in ways that jeopardize security.

Furthermore, employees or SharePoint administrators can find numerous ways to avoid putting in place the appropriate metadata classifications for documents being brought into SharePoint.

These issues are, in fact, surmountable if a savvy SharePoint administrator partners with a consultant or SharePoint vendor that specializes in securing SharePoint at the document-level.

When it comes to security, out-of-the-box SharePoint is not the best SharePoint. Much like any bank has vaults, alarms and other systems that augment the bank building’s security, SharePoint administrators must find or create resources that can help them make SharePoint more secure.

When deciding on whether to create a document-level or folder-level security strategy, SharePoint administrators should remember this: SharePoint is all about collaboration, and for collaboration to be successful it must be secure.

Given the percentage of data loss instances that involve human error, and folder-level security’s reliance on human perfection, SharePoint administrators must look to the document level when securing SharePoint environments.

Kurt A. Mueffelmann is president and CEO of HiSoftware. Mueffelmann draws on over 15 years of experiences in helping high-tech companies reach their growth potential. He is responsible for defining and directing HiSoftware’s worldwide strategic and operational direction, product strategy, sales and market expansion and international growth activities. Additionally, Mueffelmann is a member of HiSoftware’s board of directors.