Kickstart Your M365 Implementation – Five Key Configurations

M365 implementations are common among organisations of varying sizes. We have recently completed an engagement to review the security configurations of one and decided to create a review framework. This post covers five key configurations that kickstart the security configuration of your M365.

As a starting point, it may get overwhelming with all the components linking together to form the infrastructure. Several systems may include, but are not limited to, the Microsoft 365 Defender Portal, Defender for Cloud Apps, Microsoft Purview Compliance Manager, SharePoint Admin Center Portal, Exchange Admin Center, Azure AD Admin Center, Teams Admin Center, and Microsoft Endpoint Manager Admin Center (Intune). There are many elements to handle at once, and we understand the complexity this may bring to the initial design and implementation.

Hopefully, as you read through, we can make the implementation less hindering and more attainable by focusing on the following five key implementation strategies. This post would be one of many blog series we cover on the topic.

Our Top Bottom Approach

Here, we shed light on the most critical assets first. We like to highlight five key configurations as our initial kickstart. The list goes in the order of priority:

Enforce MFA for all Administrative Accounts Including Your Break Glass Accounts

We advise all our customers to enforce MFA for all administrative accounts. It is as important as having the accounts themselves.

Having emergency accounts is essential and would serve your organisation in times of crisis. It is as essential to set up strong authentication. Predominantly, have a different authentication method than the other administrative accounts. For example, if the administrator account uses the Microsoft Authenticator app for strong authentication, we would advise to use a FIDO2 security key for the break glass accounts.

Here is a little more on what Microsoft recommends on setting up MFA for your emergency access accounts.

Establish PAWs for High-Privileged Activities

To reduce the attack surface, Administrators need to do their privileged activities using PAWs (Privileged Access Workstations). It would ensure that administrative workstations become less likely to be compromised since they are only used for specific tasks and for a limited time.

We recommend having your PAW in a separate group with formally approved strict access rules (including firing up the PAW). We also advise that any access to the group generates an alert that your analysts would monitor actively. The notification has to correspond to a service ticket that outlines a window that warrants using the PAW. The service ticket has to be approved by a designated authority in the organisation.

To implement PAW in your infrastructure, we recommend the following:

  • Use hardened and dedicated devices that are monitored for keystroke logging, applications running, command line tools and inbound and outbound network connections.
  • Operate the PAW based on the least privilege principle throughout.
  • Disable all unnecessary applications and processes.
  • Setup modern hardware (if you are using a physical PAW) that supports TPM 2.0 (Trusted Platform Module).
  • Require MFA for authentication (preferably different than the one used for other machines in the network).
  • Operate in a highly segmented network and use wired network connection (if you are using a physical PAW) to manage your devices.
  • Use a physically secured machine (if you are using a physical PAW) with tamper cables to prevent theft (especially if your PAW is a laptop running in a high-traffic area).

Do not use your PAW for any of the following:

  • Browsing the Internet or using email and other messaging services
  • Attaching any storage devices

To further implement better strategies for your PAW, we advise checking out this post by Microsoft as they recommend a privileged access strategy to lower the attack surface towards your privileged access devices.

Strip Off Unused Admin Accounts

In several scenarios, you may have one or two administrative accounts lying around that were provisioned for your administrators who may have left the organisation or recently been assigned to other tasks or functional units.

Here, we look at monitoring key accounts that are not fully operational by a particular user. We advise deleting, disabling, or blocking access to those accounts, especially ones with high privilege. It may have a high severity impact as they may be used to escalate privilege throughout your tenancy and perhaps laterally move to affect other key assets within your infrastructure.

Monitoring Key Accounts

We recommend that rigorous monitoring is in place to notice any changes to both the administrators accounts and the emergency accounts. You may set up alerts through the Defender for Cloud App with regards to any of the following events and more, as you see fit:

  • Membership changes – users added to one of your key account groups
  • Successful sign-in – users signing in with an administrative or an emergency account
  • Successful sign-out – users signing out with an administrative or an emergency account

You should set up notifications and alerts on the Defender for Cloud App portal. We also recommend enabling SMS alerts to administrators. Enabling such configuration would help ensure all activities are monitored and acted upon when needed.

Segregation of Duties (SOD) on Key Accounts

A pivotal configuration and strategy to apply within your organisation is SOD, whether on a system-wide level or a particular function or task. With no SOD, you may expose the environment to erroneous or fraudulence activities which may go unnoticed.

Considering SOD as a control makes it easy to track an insider threat should a fraudulent act occur.

Therefore, we advise separating system administration activities from licensing, compliance, e-discovery, and other administrative tasks. You should have separate accounts for each role and have different personnel assigned for the same. We see the value and recommend having a SOD policy to manage your operation.

Hopefully, this post brought some light towards further maturity within your environment. You can always reach back to us if you have an idea worth sharing or a plan for an assessment. You can also reach out to Axenic if you need help securing your M365 environment.