Sometimes you read a headline, and the individual words make sense, but it’s still hard to puzzle out exactly what it means. This article is probably a good example. You already know what all the individual word means, but unless you are used to using the Office Cloud Policy Service, or unless you have been around the Microsoft security world for a while, you might not be familiar with the concepts we’re going to cover.
Microsoft and Security Baselines
Let’s start with a fairly simple concept. Some years ago, Microsoft was getting a lot of criticism for having too many settings and not providing enough guidance for customers to understand what the settings did or how they should be used. This complaint actually goes all the way back to the old Windows resource kits, which, for those of you who weren’t around then, were big boxed sets of printed documentation covering all of the different registry keys and other settings available in the BackOffice applications.
As time passed, Microsoft steadily improved both the amount and the quality of their documentation. Other organizations, including the National Security Agency and the National Institute of Standards and Technology, got in on the game and started producing their own configuration recommendations. For example, the U.S. Department of Defense produced a series of documents known as the STIGs (for Security Technical Implementation Guide).
Along with these documents, Microsoft started to produce group policy templates that would collect all the relevant settings for a particular configuration. This was very popular with their enterprise customers because it made it easy for them to apply a group policy template with the desired settings and know that it would be consistently applied to all the machines in the domain. However, the STIG recommendations were very restrictive because they were tailored at protecting defense and government systems. Their settings were much too tight for most corporate customers. Microsoft decided that they should build their own baseline of recommended settings. For example, here is the current set of Microsoft baseline settings for Windows.
One Minor Problem with Baselines
The problem isn’t actually with baselines. The problem is that not every device you might want to manage is joined to a domain of on-premises Active Directory. Group policy objects don’t do you any good if your users are bringing their own devices, or if you are using devices that are joined to an Entra ID domain. To help resolve this problem, Microsoft introduced the Office Cloud Policy Service.
The intent behind this service was to give Office 365 administrators a way to push policies to any device that was connecting to their tenant and running Office. These policies only affect the Office applications. You can’t control things like screen lock time or password requirements. For that, you need Intune or some other device management solution. Still, having the Cloud Policy service makes it much easier to consistently apply settings across your Office fleet.
Applying Baselines with OCPS
I have some good news and some bad news. The good news is that you can apply recommended baseline security policies for Office applications using only the Cloud Policy Service. You get that service for free with your E3 licenses. So you don’t have to buy anything or deploy anything. The bad news is that those policy settings are not grouped together so applying them can be a bit of a pain. The good news (again) is that if you’re not already using OCPS it’s simple to set up a policy for all users and put some baseline settings in it, and you only need to do that once to greatly increase your overall protection against Office-based threats.
Creating a New Tenant Policy
OCPS supports multiple policies and allows you to order them by priority. You can have a single policy that automatically applies to all users in the tenant; additional policies must be scoped to a specified set of groups. Assuming you don’t have an existing tenant policy, it’s simple to set one up:
- Log in to config.office.com using an account that has Global admin or Office Apps Administrator rights.
- On the left nav rail, select Customization > Policy Management.
- Click Create to create a new policy, then give it a name and description and click Next.
- On the Choose the scope page, make sure the This policy configuration applies to all users radio button is selected, then click Next.
Now you’ll be at the Configure Settings page. One deficiency in the OCPS interface is that there’s not much real filtering or grouping capability. The fastest way to identify the security baseline policies is just to click the Security baseline pivot. That will filter your choices down to the 135+ policies that are part of the security baseline for Office clients. Most, if not all, of them will show as “Not configured” in the Status column.
Policy Configuration States
Like Group Policy Objects, every OCPS policy setting has a state that indicates whether it should be enforced. Ordinary policy settings typically have 3 states: “not configured” means that the policy setting has no impact. “Enabled” means that whatever the policy setting does is enforced; “disabled” means the opposite. This can be confusing because sometimes policy names are negative: if you set the “Disable all application add-ins” setting to “disabled,” does that mean you’re disabling the disablement? (In this case, yes, it means that you’re not enforcing the disablement offered by the setting!)
Baseline policy settings have an additional option: “Microsoft recommended baseline.” If you choose that value, Microsoft’s recommendation for the policy setting will be applied. You can instead choose “Manually configured,” in which case you get the three choices previously described.
What Settings Should You Apply?
The answer to this question could fill a book. There are more than 135 settings available, and some of them are pretty esoteric. For example, most Office 365 administrators wouldn’t know what the “Do not show AutoRepublish warning alert” setting does. (I didn’t!) While I don’t have space to go through all the settings, I can identify a few general things you should be focused on when configuring your security baseline.
First: restrict what types of files can be opened and where they can be opened from. The very first policy setting I’d apply would be “Block macros from running in Office files from the internet,” for example. Restrictions on macros and opening files from untrusted locations are both fundamental security restrictions that should always be in place.
Second: pay attention to the application icons. It may not do you much good to block macros from being opened in Excel if you allow them in Word, for example. There are some Office-wide policies (shown with the square-O Office icon) but the real work you do will mostly be in applying policies to specific applications.
Third: understand that you will need to perform some testing, and/or be prepared for complaints from users, as you roll these settings out. For example, if you block the ability to open Excel 97 files (which is a pretty good idea), you may just find that someone somewhere in your organization relies on an old Excel 97-format file to do their job.
Since OCPS doesn’t cost you anything extra, it’s well worth some of your time to investigate the security baseline settings and decide which ones make sense in your environment. A small investment of time can add significant security protection.
