Introduction - Microsoft Entra ID and Microsoft 365 Suite
As the influence of the cloud has increased over the past 10 years, Microsoft have rolled out their cloud-based identity and access
management solution called Entra ID. With this, organization could transform their on-premises Active Directory into a hybrid or even
full-cloud based environment. As Entra ID and subsequently Microsoft 365 (including OneDrive, SharePoint, Microsoft Defender, Exchange,
etc.) have matured, the platform has increased its vast array of security configurations and policies that aim to safeguard these
hybrid- or full-cloud-based tenants from threat actors.
The vastness of the Entra/M365 suite ensures that customers can use, enable, and implement a broad range of security settings and
features. This allows for fine-grained control over the Microsoft Tenant whilst simultaneously resulting in the need for experienced
administrators that are intricately familiar with the platform.
Exactly this challenge is what we aim to address in this blog post.
About Microsoft Graph PowerShell
Both new and experienced organisations can have a hard time keeping up with the ever changing landscape of M365 products. For organisations that are new to the M365 suite, a new world arises with seeminly endless possibilities and at least as many portals, admin centers and configuration screens. If we look at the array of products included in a M365 Enterprise subscription, which is comprehensivly shown thanks to M365Maps.com, it is no wonder that even experienced organisations may overlook a setting or two to increase either security, resilience or comfort.
By providing M365 Tenant Security Maturity and Modern Workplace Assessments, the goal is to provide a comprehensive overview of completeness, by checking all known locations for settings that improve security, resilience, logging, monitoring, etc. As an example, on average each assessment would include Microsoft Entra, Microsoft SharePoint, Microsoft OneDrive, Microsoft Defender for Endpoint, Microsoft Defender for Cloud Apps, Microsoft Exchange Online, Microsoft Intune and Microsoft Defender for Office. In the early days, this assessment was done by hand, having to go through each admin portal and configuration webpage and single-handedly checking each setting one by one. With proper documentation lacking, anyone doing the assessment would additionally have to spent some extra time to research where specific settings could be found - for over 100 settings a devilish task.
In an attempt to maximize my output, I researched other avenues to perform the security assessment that would drastically lower the amount of manual labor required. I had previously heard of the Microsoft Graph API but had not really used it. The Graph API, a RESTful web API that enables access to Microsoft Cloud service resources, would become to be my go-to solution, with its native support for M365 and helpful Azure commands, as well as several Microsoft PowerShell modules specific for Exchange Online and Teams for example.
The challenge in automating this process lays in finding the right balance between automating the decision if a specific toggle should be turned on or off based on security good practices, industry benchmarks, internal knowledge and additionally taking the organization's context and challenges into account, as well as the general industry and threat landscape to be able to account for exceptions. Solving this challenge will be indirectly discussed during the upcoming chapters, where the automation of the assessment of an organization's security maturity is discussed.
Adhering to Zero Trust and the principle of least privilege
Let's first discuss an arguably understandable worry of clients: running foreign scripts with permissions in their environments. Clients, understandably, are in general hesitant when it comes to unknown scripts and privileges to third-parties, even when these third-parties provide security services. By relying on the Microsoft Graph API, we were able to provide clients with a natively supported interface within their M365 environment that allows for heavy restriction, usually raising exceptions and logon failures if actions are performed without the right permissions or are downright blocked. Fortunately, it is quite easy and effortless to allow the Graph API within an environment whilst simultaneously reducing the access that it obtains. Through creating an application registration within the Microsoft Entra Admin Center, one can specify the API permissions that should be granted to the Microsoft Graph API. In this case Microsoft Graph API can be granted a limited subset of permissions to perform its task. Although a wide range of permissions is required to perform the automated tenant assessment, it is limited to "read" rights, which limits the privileges that are obtained by the application registration. Furthermore, the organization can then on a as-needed basis add users to the application registration. As a result, only a single instance exists where users obtain limited permissions to read configurations and when the application registration is removed, no privileges are inherited by users.
Developing the automated tenant assessment
The clients that I have come across usually run either Microsoft 365 Enterprise 3 (E3) or Microsoft 365 Enterprise 5 (E5) licenses. By taking the distribution of products from M365Maps.com website as the ground truth, I have created 5 main assessment sections for E3 licenses: Entra ID P1 Intune P1, Defender for Endpoint P1, Office 365 E3, Windows Enterprise E3 and Defender for Office 365 P1, EMS E3 (separating Entra ID P1 and Intune P1 from EMS E3). Note that Defender for Office 365 P1 is a stand-alone license that most clients have added on top of in their M365 E3 license. For E5 licenses, I have created 8 assessment sections: Entra ID P2, Intune P1, Defender for Endpoint P2, Defender for Office 365 P2, Office 365 E5, EMS E5, and the add-ons from M365 E5 Security and M365 E5 Compliance.To be able to call the Graph API cmdlets, and use the cmdlets offered through the Teams and Exchange Online modules, we will need to install these three modules, before we can continue automating: Install-Module Microsoft.Graph, Teams, ExchangeOnlineManagement -Scope CurrentUser
In the end, I ended up creating a custom PowerShell module that users can import. This allows for a high flexibility and modulality of the assessment. Assessors can either run the Get-FullE3Report or Get-FullE5Report cmdlets which wil perform a full assessment over all the assessment sections, or call the individual assessment sections to get a dedicated report.
To account for non-technical assessors having to interpret, analyze and understand the results, I relied on HTML and CSS to help me out. By developing a clean and simple dashboard, the results would be categorized by their assessment sections and each result would be displayed in a separate modal. The modal includes not only the assessment results, but supports further functionality so that assessors could find out the point of the specific test, the expected results and both a recommendation and supporting reasoning for the expected result. The aim of this, was to ensure that it could be transfered into a report without someone having to look up the reasoning for or against enabling specific settings, and a default template was given. Of course, each recommendation is generic, meaning that assessors would still need to analyze if the environment they performed the assessment in, would by default benefit from the recommendation. As you might imagine, I can't freely post the full assessment PowerShell module here, but I am happy to discuss details and ideas.
A short demonstration
The chosen framework to build the automated tenant assessment in is PowerShell. It is natively supported by Windows and provides the most versatile solution for the multiple APIs and Graph SDK that are used.An example of lowering the manual labor required for obtaining all security-related settings can be demonstrated through the Endpoint DLP Settings in the Microsoft Purview Compliance Center. The Endpoint DLP Settings contain 14 main configurable settings of which multiple have subsettings that allow for an even more finegrained configuration additionally. By manually going through every setting, a lot of clicking and opening of subviews etc. is required. Additionally, one needs to properly document where these settings are located and doing that for every single setting requires a lot of documentation. Furthermore, as Microsoft continuously improves and changes the layout of their products, it is likely that locations of these settings may change, which requires that the documentation on where each setting is located needs to be checked and updated in the documentation.
On the other hand, Microsoft provides through the Security & Compliance PowerShell a single cmdlet
Get-PolicyConfig
$ClientId = "a0a0a0a0-0000-aaaa-0a0a-a0a0a0a0a0a0"
$TenantId = "f9f9f9f9-9999-ffff-9f9f-f9f9f9f9f9f9"
Connect-MgGraph -ClientId $ClientId -TenantId $TenantId
$dlpSettingsObject = Get-PolicyConfig
$dlpSettings = $dlpSettingsObject.EndpointDlpGlobalSettings
if ($dlpSettings) {
foreach($dlpSetting in $dlpSettings) {
if ($null -ne $dlpSetting.Value and $null -ne $dlpSetting.Setting) {
Write-Host "$($dlpSetting.Setting): $($dlpSetting.Value)"
}
}
}