SharePoint Server Security: 8 Best Practices Your Company Overlooks
The best part about SharePoint is that it is easy to set up and start using. This is also the worst part about SharePoint Server security. An inexperienced IT admin can easily get it up and running but, more often than not, optimal security practices are not built into it. The entire system and those confidential documents most likely contained on your organization’s SharePoint are susceptible to exploitation.
Don’t fear though, whether you are just starting to implement Office 365 or you’ve had it for years, this list will get the wheels turning and make sure all your bases are covered in terms of securing SharePoint servers.
1. Separate the SQL Server from the SharePoint Servers
This is priority number one for small business since they are most likely to have their SQL and SharePoint data all hosted on the same server. Most large organizations have it separated to begin with, but just in case you don’t, here is your friendly reminder to separate them sooner rather than later.
The main reason for this is that it shrinks the potential attack surface. When all your data is housed in one place, a hacker only needs to infiltrate one place. Your SharePoint SQL server is intended for storage purposes. It houses data from your SharePoint lists and libraries and your configuration settings. Your SharePoint server(s) on the other hand contains data pertaining to your web front end, app/search and indexes.
2. Encrypt SQL Server Data
Out of the box, this data does not come encrypted. Just like above, don’t make it easier to exploit your confidential information. Remember that in most businesses, SQL Server contains information pertaining to:
- Customer names
- Bank account or credit card numbers
- Email Address
- Passwords, etc.
This Personally Identifiable Information (PII) should be encrypted for your customers’ security and to maintain public confidence in your business. In the case that your organization is held to regulations such as HIPAA/HITECH, PCI-DSS, or GLBA/FFIEC, you are already aware that this data needs to be encrypted and you are held to appropriate standards.
How Do You Encrypt Your SQL Server?
Best practices for encrypting your SQL Server state that you should leverage a hardware security module (HSM) that is held to the FIPS 140 or Common Criteria international standards. This will also provide tamper evidence controls and backup. For SQL Server 2008 and above, transparent data encryption (TDE) is included and this allows for automatic key encryption. You can your entire SQL database and then use your HSM to store your keys without any programming knowledge.
3. Only Enable Necessary Services and Ports
If you don’t need it to run your SQL and SharePoint servers, don’t use them. Unused sevrices and ports leave you open to security vulnerabilities. There are some services and ports that are absolutely necessary for you to use and they are listed below:
- AppFabric Caching Service
- ASP.NET State service (if you use InfoPath Forms Services or Project Server)
- Claims to Windows Token Service
- Forefront Identity Manager service
- Forefront Identity Manager Synchronization service
- SharePoint Administration
- SharePoint Search Host Controller
- SharePoint Server Search 1 5
- SharePoint Timer Service
- SharePoint Tracing Service
- SharePoint User Code Host
- SharePoint VSS Writer
- View State service (if you use InfoPath Forms Services)
- World Wide Web Publishing Service
4. Enable Endpoint Security
This really applies to protecting your data when your employees don’t follow security policy. SharePoint allows users to sync with SharePoint libraries in order to access content when they are offline. The endpoints in which they access this content can be tablets, laptops, desktops, mobile phones, etc.
In the event that the employee’s PC becomes compromised, there needs to be a cut off to prevent the breach from accessing SharePoint data. Endpoint security management can be purchased either as a dedicated appliance or as SaaS. Industry-recognized names such as Symantec, Kapersky and Sophos all offer top of the line endpoint security software and services.
5. Limit Access Rights and Search Views
Similar to point number three, not all employees need access to every bit of information in your SharePoint site and less is definitely more when it comes to granting privileges. Keep an eye on what employees or departments can view, edit and share and if it doesn’t pertain to their line of work, there is no shame in preventing their access.
Crimes of opportunity can easily arise by divulging too much information to an employee that has no need to know it. Studies among SharePoint users indicated that about a third of employees admitted to looking through documents pertaining to employee PII and salary information. Additionally, the SharePoint admin should also restrict search results to only a basic permissions view. Even though users can’t click through to a document they don’t have privileges for, sometimes all the information they need can be found in the brief preview text.
6. Build a Framework for Suspicious Behavior Alerts
Again, right out of the box SharePoint is not configured with such alerts, but the setup is relatively easy to alert you to suspicious behavior. First of all, you need to define typical behavior by person, department, project, etc. and each user needs to be assigned to his or her relevant role(s).
Next, create email alerts to yourself when atypical behavior occurs – you can google “how to create an alert in sharepoint” and return pages of detailed how to articles. By receiving these notifications, you are able to discuss the atypical behavior with other employees to determine the cause. This also shows them that you are constantly vigilant to abnormal changes in the SharePoint environment and it helps deter them from taking advantage of any opportunity to view, edit, download or share documents that they shouldn’t.
7. Assign Security Enforcement to a Team Member
All of the above points are useless if there is nobody assigned to enforce them. You need someone to actively create and manage your SharePoint security policies on the end user level. Some typical actions by employees that could create security risks include:
- Downloading SharePoint files to USBs, desktops, etc.
- Sharing files through unsecured email or to employees, partners, vendors who do not have authorized access to the content.
- Uploading files to SharePoint without properly scanning them for viruses first.
Your SharePoint security enforcer needs to first educate end users on SharePoint security best practices and the policies you have in place. Then the enforcer needs to get end users to buy into the policy so that they understand the purpose of these policies.
After those two points are met, the enforcer is responsible for holding end users accountable for misconduct and consistent reviewing policies.
8. Incorporate SharePoint Recovery into the DRP or Risk Management Plan
At the end of the day, there is no magic formula for ensuring that your policies are carried out or that an attack on your company’s SharePoint doesn’t result in a data breach. You have all the right presentation tools in place, but you still need to have a preparation plan for when disaster occurs.
As a company, you should already have a risk management or disaster recovery plan (DRP) in place, but as the SharePoint administrator you should also ensure that part of that plan reflects procedures and actions specifically related to data recovery. This plan needs to be customized to your organization and how it operates. To get started on writing it, just download our Risk Management Planning Guide on the right.
Subscribe to the TechRoots Blog