Delegated user auth support for the MDATPDriver

[ryan-detect-dot-dev]

Context

Defender changed how it handles API permissions multiple times in the recent past, so the MDATPDriver is responsible for selecting the correct resource, scope name, API URI, and login URI:

API Name	Resource ID	Scopes Requested	API URI (global cloud)	API Endpoint	Login URI	MSTICpy Data Environment
WindowsDefenderATP	fc780465-2017-40d4-a0c5-307022471b92	AdvancedQuery.Read	https://api.securitycenter.microsoft.com	/advancedqueries/run	https://login.microsoftonline.com/<tenantId>/oauth2/token	MDE, MDATP
Microsoft Threat Protection	8ee8fdad-f234-4243-8f3b-15c294843740	AdvancedHunting.Read	https://api.security.microsoft.com	/advancedhunting/run	https://login.microsoftonline.com/<tenantId>/oauth2/token	M365D
Microsoft Graph	00000003-0000-0000-c000-000000000000	ThreatHunting.Read.All	https://graph.microsoft.com/<version>/	/security/runHuntingQuery	https://login.microsoftonline.com/<tenantId>/oauth2/v2.0/token	M365DGraph

The msticpy.data.drivers.mdatp_driver.MDATPDriver is a subclass of msticpy.data.drivers.odata_driver.OData with a few key differences. The MDATPDriver class only allows confidential client credential auth flows using a secret, while its OData parent class supports both application and delegated user auth flows. This is because the Defender APIs previously did not allow delegated user auth. The MDATPDriver driver also determines the correct casing on some of the field names in the responses.

Problem

The current MDATPDriver class only supports authentication using a client secret and application permissions. The use of secrets is not allowed per the Secure Future Initiative.

Proposed Solution

Update the MDATPDriver class to allow delegated user authentication.

1. Ensure that msticpyconfig.yaml permits MicrosoftDefender.Args without a defined ClientSecret
2. Refactor msticpy.data.drivers.mdatp_driver.MDATPDriver to support delegated user auth