Top five M365 Misconfigurations

1. OneDrive and SharePoint sync and access control

OneDrive external sharing settings are normally left with overly permissive settings as this is the default. Sharing files externally from your organisation can be set at four levels:

• Anyone - allows anyone with the link to access files or folders without authenticating
• New and Existing guests - requires anyone who has received the link to sign in with an account or code first
• Existing Guests - only allows sharing with users who are already in your directory
• Only people in your organisation – turn off external sharing.

By default, this is set to ‘Anyone’ allowing anyone with the link to access the files or folders that you have already shared without any authentication, exposing your data without much trace of who is accessing it. N.b. This only affects files and folders you have shared. 

We recommend reviewing this regularly to ensure it is still appropriate to your organisation’s sharing policies. 

Another common setting we see left without change is the type of link that is selected by default when users share files and folders. By default, this is ‘Anyone with the link’, however we recommend changing this to ‘Specific People (only the people the user specifies)’ instead. This reduces the risk of an employee accidently sharing with more people than originally intended, and forces them to think about who they want to see the document, and what they can do to it when they can. 

Finally, reviewing settings on what devices can access OneDrive, from where and what they can do. Examples of this would be where any device is able to login and sync the data locally with their machine, which can cause you to lose track of the data - especially if a user that has synced data with a personal machine were to leave. We recommend reviewing these settings and only allowing local sync with devices you trust (managed devices), or stopping anyone outside of the organisation accessing OneDrive/ SharePoint using Conditional access policies.

2. Conditional access policies

Conditional access policies are becoming a bigger part of Entra ID, and are beginning to be adopted more and more by organisations, however sometimes they are setup with someone in the IT team ‘playing’ with the policies to test them out, and from there they just become live. We have seen a lot of conditional access policies be left in ‘Report-Only’ mode where people thought they were ‘on’ and working. MFA for all users has been added, however exclusions have also been added that exclude too many users, or where a group has been added that requires a user to be added to it to require MFA, and this has been missed from a JML (Joiners, Movers, Leavers) process, therefore not having the whole user base protected. Finally, where named locations have been used to allow or block access from certain locations, but these have not been kept updated over time. This could mean more locations are allowed than initially intended or users might be denied access due to changing IPs, neither being ideal situations. 

We recommend that conditional access policies are regularly reviewed and updated to ensure they are still fit for purpose, cross checking against Microsoft best practice. We also recommend following a conditional access policy architecture/ framework to implement policies.

It’s common to see policies configured in reaction to specific problems, rather than in a constructive way that supports manageability.  

3. Message hygiene

Email message hygiene has gained significant importance recently due to increased email usage, increased spam, and smart email services. There are several protocols that help secure email communication and maintain email hygiene including SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-Based Message Authentication, Reporting and Conformance) as well as some other specific protocols. Implementing these three main protocols enhances your organisation’s email security and reputation, reducing the likelihood of your messages being categorised as spam or ignored, as well as giving your recipients greater confidence in the legitimacy of emails coming from your domain.

SPF is quite simple to configure with limited effort or knowledge, however DKIM and DMARC involve more knowledge of the systems you have that are potentially sending emails, and sometimes working with vendors to configure DKIM and DMARC correctly. We recommend investing time into ensuring all three of these protocols are enabled and configured as a minimum.

4. Risky users and sign-ins

Entra ID Identity Protection identifies sign-in risks and unusual behaviour to limit or block access to Microsoft 365 by assigning a risk to a user or a sign-in that can be tracked and alerted on, depending on license level. Risky sign-ins are based off event types including, impossible travel, password spray attacks, malware linked IP address and more. Risky users are those that have one or more risky sign-ins, or there are one or more risks associated with a user, e.g. leaked credentials, suspicious sending patters, a user reported suspicious activity and more.

By default, all Entra ID plans have this feature, however you must have Entra ID P1 to use Graph API to receive results, or P2 to start getting inbuilt automated alerts.  

Often if there is not an automated email to the IT Team, these alerts don’t get looked at, which can start causing issues for a user logging into Microsoft 365 and other services using Entra ID as an identity provider. 

One of the main ways that we have seen more recently is where a user has a risk automatically assigned and has had a link shared to them from another business they are collaborating with. When they try and authenticate, this other business has risk-based access policies configured which then stops the initial user from authenticating. This could be avoided if there was a task to ensure all risky user and sign in alerts are investigated and actioned as they occur. Risk policies and self-remediation require Entra ID Premium P2, however can be configured to interrupt a user logging in with additional prompts e.g. Multi-Factor Authentication. If this test is passed, then the risk level is remediated. This should be implemented extremely carefully.

5. Secure Score

Finally, we have Microsoft Secure Score. This is a series of measurements around an organisation’s security posture. In simple terms, the higher the score the better, and you can increase your score by configuring recommended security features and completing security related tasks. The recommendations are specific to your tenant, and give you information on what the recommendation is, what the user impact might be and how to implement the recommendation. 

We hear more regularly that people are not sure what to do, Microsoft have released too many new features and now are not sure what to do to maintain a secure Microsoft 365 tenancy. Microsoft understand this and have given this platform for IT teams to work off this a priority list of recommendations, so if you are unsure what to do or what changes to make, take a look at your specific Secure Score recommended actions.

To find out more about how you can avoid M365 misconfigurations, and make the most of your 365 environment, join our Couch to 365 community here: www.couchto365.com 

Or contact christopher.rich@waterstons.com