As you know, I enjoy working with SharePoint, Office 365 and of course the Security for that. I have spent a lot of my working career always drawn back to customizing the core platforms for clients. Some of these customizations would be classed as less-invasive where others completely overtake the end user experience. SharePoint has always been one of the products that you like the user experience and design, or you don’t. Rarely have I ever had a client ask me to keep it completely out of the box, there are always required changes.
What kinds of customizations do you mean?
Anything from a Cascading Style Sheet (CSS) change, to a full-blown .NET solution are all classed as customizations, as it is different to what comes out of the box. In fact, I have spent time in the past tracking down issues with the User Interface (UI), which was caused by bad CSS, so they all matter.
More recently, Microsoft has encouraged customization of SharePoint, by using client-side coding solutions, versus managed code such as C#. In fact, the ability to deploy custom C# assets no longer exists within SharePoint Online giving us a clear sign that the full-trust mechanism is not for the cloud unless you are one of those customers paying for Office 365 Dedicated. Microsoft has transitioned through various approaches over the lifespan of SharePoint. There are two types of customization, one being the Microsoft Prescribed and then the Informal which is more common.
The Microsoft Prescribed approach comes with guidance and often samples, however, in the past, that was a little rare. It is common that a dedicated developer-type resource would implement, due to it requiring deeper knowledge of this type of customization. The Informal approach is really about being less-invasive by injecting client-side code into the User Interface (UI), instead of server-side code. Normally this is completed by non-developer power users, using available code snippets found from internet searches and blogs.
There are advantages and disadvantages to each approach, and we could pontificate for years on which one is best overall. The best solution is the one that you as an organization has chosen, developed or purchased, tested, secured and now manage. If you are not doing any of those key steps, then you have the wrong approach no matter which option you chose.
What are the problems with customizations?
There aren’t any real problems as such with customizations if you assume the risk for them and own them. If you simply just grabbed the code from the internet and added it to SharePoint with no code review, testing or security analysis then honestly that’s on you as an organization and let’s be honest, shame on you when there is a problem. Sounds silly I know, but that is how it is. I have spent way too many hours of my life reviewing implementations, asking the questions and highlighting the amount of unsanctioned client code, or deployed solutions that are within an environment.
It is your responsibility to validate the solutions and code deployed into your SharePoint On-premises or SharePoint Online platform. Just because a Vendor created it, or you have great developers does not remove the need for these checks. Now if you can show a full lifecycle of “checks and balances” for the solutions, and you proactively monitor and almost vouch for the customization backed with data and results then you win.
If you look outside of our little bubble of SharePoint and Office 365, you can quite clearly see attacks that compromise systems are getting more sophisticated, and harder to find, especially if no checks are being completed by your as an organization. As an example, so far in 2018, there have been many Data and Security breaches using many different methods.
As you can just by looking at the categories, you can see that a high percentage of the Data and Security breaches were caused by “Internal User Attacks” or worse “Internal User Failure.” Due to the high number of internally based breaches, the need for organizations to do better in risk assessments and security auditing is now high.
What can I do to mitigate the risks?
To mitigate risk, you first need to understand the risk assessment model. Within each industry, there are risk assessment models you can use. For software this can be separated into four core areas:
The four core areas are: Discover, Assess, Strategize then Execute. Each area has core tasks that lead to other tasks and actions that ultimately define the risk for a specific component. In the world of SharePoint customizations, this can be followed using manual processes. It is not easy but achievable. It requires the organization to invest in individuals, teams and time specifically for this.
The downside is that many organizations just aren’t designed that way and cannot simply invest money and time into a dedicated team specifically for assessment of applications. Meaning that often these tasks are assigned to already busy team members, who do not have the necessary skills to perform these types of assessments. What happens is that questions get asked, the code tested (only functionality), deployed and then no-one worries about it again unless there is a problem.
Call to action
So back to the question I posed in the title: Is it s problem to Customize SharePoint? Yes and No, based on adopting the policies, controls and practices for the management of them.
For me, if there is one thing I would encourage all organizations to do, is to make this type of auditing, assessment, and remediation a mandatory part of an overall Application Security process. Maybe you can’t afford a dedicated team, but team members can get trained on the processes, or 3rd Party solutions acquired, that goes a long way towards mitigating many of the risks faced today. Many vendors provide tools to help assess code, customizations as well as provide remediation steps. However, when selecting a vendor to choose, ensure they fully support the platform you are using. In reality, when working with SharePoint On-premises and SharePoint Online, the only vendor that truly supports these customizations comes from the team over of at Rencore.
Shameless plug I know, seeing as I work as the Product Owner for Security, however, the tools go a long way to helping you mitigate many of the risks seen today, and define processes to capture better and control them before they reach production-ready system.
Are you a SharePoint Administrator?
If so, join Waldek and me, on July 11th for a Webinar. We will discuss how to avoid risks before you deploy SharePoint solutions to your production environment.
https://rencore.com/webinars/avoid-risks-before-deploying-sharepoint-solutions-production/?lp=1
