The tyranny of search engine optimization forced me to give this article that boring title, but honestly I wanted to call it “Rubber Baby Buggy Bumpers” . One of the big myths we have in the Information Technology world is that security is a mature and solved problem. In reality we just want to get the baby buggy bumpers in place to keep us from hitting our heads on sharp corners, we have to keep watching for risks and adapting our plans as the landscape becomes clearer.
If you are looking for how to create and use “Security Policies” in Microsoft 365, don’t go away. Everything in this article should be done before you begin using policies that apply to content. We will get to building policies soon, don’t worry.
Let’s highlight a few things that you have to confront in your security discussions.
- There is no “magic” right way that works for every organization.
- You DO need a written security policy!
- Getting Started
- Identify the minimum level of protection needed
- What’s Next?
There is no “magic” right way that works for every organization.
There are lots of things that are broadly recommended, but you can’t just download a policy, or hire someone to build one for you without making some decisions and giving some input. The way your workers need to work is worth considering and you can’t force impractical solutions onto them when it just gives them reasons NOT to do things within the policy. “Security always comes at the cost of convenience.” This sentiment, while partially true, is not a license to force users into impossible situations. Just because 2 factor authentication is highly recommended doesn’t mean that you can force users who work in areas with poor mobile reception to use SMS messages for their authentication process. If they can’t get SMS messages, they can’t do their job. There are other ways to use 2 factor authentication, be sure to understand your users needs before locking into one.
You DO need a written security policy!
Security is a complex thing, too complex and important to leave to a loose understanding. Lots of frameworks, like HIPAA and Sarbanes-Oxley require a written policy in fact, so having a clear, documented, process to fall back on when there are questions or concerns is always a good plan from a governance perspective. The document has to be an evergreen, adaptable roadmap, but people can’t follow rules they don’t know or understand. The rules need to make sense, be possible. Most importantly they have to really accomplish your organization’s goals. This is a long-winded way of saying you probably can’t do an internet search for “security policy”, download a document, search and replace to put your company name in it and call it done.
Just because there isn’t a policy you can download and put your name on doesn’t mean you have to start from absolute zero. Here are a few ideas.
- Identify what you need to protect (Everything is only kind of an answer, so next…)
- Identify the minimum level of protection needed (in some organizations this may be all you need)
- Identify information that needs more than the minimum
- Finally, while doing all of that, honestly evaluate which data you can remove entirely. In some cases that will be data you actually should get rid of. Keeping too much data is often a liability. Records retention rules and laws are about what you must keep and what you should eliminate.
So that all looks pretty simple, right? In some ways it is simple, but in another way this is the HARD part. It requires people to actually think about the documents and spreadsheets they have been thoughtlessly shoving onto the file server for a decade and decide how important they really are.
So “Identify what you need to protect” is a pretty basic step. Things get cloudy at the next part.
Identify the minimum level of protection needed
The default level of protection offered in Microsoft 365 is described like this: Data is encrypted and available only to authenticated users. Data is encrypted while it resides in the service and in transit between the service and client devices.
This is probably better than the default most organizations maintain for their on-premises operation. The databases are probably not encrypted, neither are the connections to the devices in the network. The VPN is encrypted, yes, but not all of the content resting on the file share.
If you need to take it up a level, Microsoft 365 Data Loss Prevention (DLP) and Azure Identity Protection (AIP) can be used to further enforce permissions and create policies around particular information.
With Data Loss Prevention (DLP) you can (with some preparation) :
- Create policies to prevent the accidental sharing of particular categories of information. Social Security Numbers, credit card numbers, health records, etc.
- Identify sensitive information across most Microsoft 365 locations, Exchange Online, SharePoint, OneDrive for Business, and Teams, or you can choose specific locations within those services.
- Extend the above protections into the desktop Office applications. The Microsoft 365 versions of Office include the ability to work with DLP to identify information you would like to have treated as sensitive.
- While some people see these kinds of policies as way to block access and sharing, they can also be used to warn users via email notification and give them tips on how to comply with relevant policies or override them with a proper business reason. These tips also with the Office 365 desktop applications.
- DLP reports let you get an overview of content that matches any policies you make and, if a policy allows the use to override its warnings you can see that activity.
For the most advanced security and compliance scenarios Azure Identity Protection (AIP) help automate detection and response to identity based risks. Things like unfamiliar IP addresses, unusual travel, or attack patterns Microsoft security teams have noted over time. AIP in particular can have some licensing impact.
This is a fairly long start to the topic of building proper plans for security, but hopefully I have conveyed the idea that this isn’t just a matter of checking a few boxes and running a couple of PowerShell scripts. At one time there were a number of group policies floating around for on-premises servers that were meant to “harden” the servers from a number of security threats. Administrators would read about them or download them and apply them throughout their domains and hope they provided all the protection they needed. Today people are hoping for a similar approach, a list of “Best Practices” that they can quickly apply without fully exploring the options to meet a “recommended” level of security. As this series of blogs goes on we will explore those “Best Practices”, but the first one will always be to work with your business users to make sure they are appropriate to your organization. There is a lot of diversity in the business world now that Information Technology is not just something you see in technology areas. Healthcare is different from banking and both are different from agriculture and finance, but all of them depend on varying levels of technology to get work done. Even very recent events have taken away one of the favorite strategies of the most conservative organizations, namely locking ALL activity to a certain small set of IP addresses coming from particular locations. Remote work has suddenly become more prevalent and complex. Security must keep up, because the way things used to be done have to be changed. Microsoft 365 is designed to work in these situations, and with a little thought and guidance the transition to a more open, but still secure environment is very possible, and in many ways will offer some unexpected benefits. Stick with me and let me know in the comments if you have any specific directions we should explore.
On June 4th I will be teaming up with Joy of SharePoint to cover this topic in a webinar. In true JOS form we will break-down this information and welcome your questions.