This is part 2 of a longer series in securing SharePoint Online as part of securing Office 365. The purpose of writing this is to provide a more comprehensive look into the aspects of SharePoint Online security, especially for those who might not have extensive experience in working with SharePoint Online yet.
The whole series contains the following articles:
- SharePoint Online and security: Overview
- Securing users and admins (this article)
- Securing content in SharePoint Online
- SharePoint Online external sharing and extranets
- Advanced security with Azure Active Directory
First things first: What do we need to secure?
It’s obvious we need to make certain that both our administrators and users are secured. For a long time common practices have followed these guidelines:
- Ensure users have a complex password, ie. Instead of Password1 it should be [email protected]
- Have users change their password at regular intervals – perhaps every 30 or 60 days
- Admins should use separate accounts, as opposed to have fixed admin privileged with their regular accounts
Obviously, this isn’t everything there is to it, but it’s often deemed the minimum when thinking about security for SharePoint Online. To be clear, there is nothing wrong with these guidelines – that is why many of these have been a recommendation for years.
In late 2017, Microsoft updated their guidance on this, especially for Office 365 related password security settings. You can read the guidance here. In essence, the current recommendation that we are interested in the context of this article is to turn on two-step verification (multi-factor authentication in Microsoft language), and banning common passwords.
Getting the baseline
We need to map our baseline to begin our journey for the better in SharePoint Online. Luckily there’s a free, easy to use and quick service to ascertain this – Secure Score. You can reach the service at https://securescore.office.com. The service scans through the essential security-related Office 365 tenant settings and provides a clear and no-nonsense scoring for this. You can also compare scores over time, as many settings might change with changes other admins are doing.
One of my tenants has a score of 62, out of 364. This is quite poor, as many basic settings have been left in their default position and the tenant is far from a secure environment. Below this we’ll see a slider for setting our target.
It’s important to notice there’s actually a maximum score beyond the aforementioned 364, which at the time of writing this is 435. I can use the slider to set my target anywhere in this range. It’s probably a safe assumption to state that the highscore is quite challenging to achieve should you make life not too hard for your users.
General rule of thumb is simple: aim for a score of over 100. Once you set the slider above, which for me is 112, there is only one action to perform: enabling multi-factor authentication for all global admin accounts. Should I need to enable the same setting for all of my users also, I would get a score of 142, which is far beyond the average Office 365 score world-wide (currently this is 40).
Moving the slider all the way to 435 gives me 44 actions to perform. Many of these are very reasonable to enable in one sitting, such as setting outbound spam notifications generated from your tenant, and review the different security-related reports weekly. Others, however, require more planning – such as requiring mobile devices to forcefully wipe data on multiple sign-in failures from the user. I can only imagine the horror of a user mistyping their password for too many times and finding their device wipe in front of their very eyes.
While users also benefit from MFA, it also requires a planned rollout, education and support to successfully enable it. The planning documentation is quite comprehensive, and touches upon the aspects of who to best enable this somewhat tricky setting for your users.
I find it important to enable MFA for all users, while also maintaining a non-hostile approach. Things to consider for MFA are:
- Do we need to enforce MFA while users are connected through a trusted network, such as the corporate LAN?
- Should we allow users to bypass MFA at certain times, such as when they perform authentication multiple times a day?
- Should we enable App Passwords as a way to bypass MFA at times when an application does not support authentication in modern ways?
- What happens when a mobile device is lost?
- How do we support our users in enrolling for MFA?
MFA itself is not the means to an end, it’s simply a rather preventative way to secure majority of the issues many companies might face today with their employee identities and access.
The tool thus gives a clear list of actions you as an admin should perform. Let’s have a look at the first task – enabling MFA for all global admins. You’ll get a list of impacted users, and a tool for informing your users about the change.
For MFA, as there are multiple services this setting forcibly affects, it’s best to first practice the setting on a test global admin account before forcefully enabling it for all of your admins.
Once you enable MFA for a global admin, it will require changes for how you perform remote administrative tasks such as connecting to different Office 365 services through Powershell. The latest guidance on this tells us that the process differs slightly for each service. Connecting to some of these, Exchange Online as an example, becomes a bit more trickiers so it is important to educate each global admin about these changes.
Reviewing and monitoring global admin access can be done with a separately licensed service in Office 365 called Cloud App Security. This is accessible through the Protection Portal in your Office 365 tenant, and has a separate portal for managing all the aspects. While CAS is very capable, it also has several settings and views that we’ll look in more depth later in this series.
For now, we need to create an anomaly policy to detect what your global admins are doing with their unlimited powers. CAS gives us plenty of options to monitor, and as a good starting point we can monitor all activity and all risk factors. Here’s a sample of the these:
When an anomaly is detected for a privileged account, we can simply send an email. This email can then trigger something more advanced, such as a Microsoft Flow or Logic Apps workflow, which in turn does more advanced changes for us.
In this article we had a look at a few important services – Secure Score, Multi-Factor Authentication and Cloud App Security. Together these three services provide a cornerstone of strengthening the security of your Office 365 tenant, services, users and data. In the upcoming articles we’ll dive even deeper to these services, as well as other services that additionally provide more security, monitoring capabilities and trust in securing SharePoint Online and your users.
Over to you
Whether created by the development team or business users, applications are often the root cause of poor SharePoint health. Run the free Rencore SharePoint Applications Health Check App on-premises or online to find issues in your SharePoint applications. For more information and how to download, click the button below.