Skip to content

Latest commit

 

History

History
756 lines (526 loc) · 122 KB

IdentitySecurityMonitoring.md

File metadata and controls

756 lines (526 loc) · 122 KB
Raw

Appendix: Overview of Microsoft Identity Security Monitoring

Author: Thomas Naunheim

Created: December 2020, Updated November 2022

Microsoft offers several solutions and services for securing (hybrid) identities and protecting access to workloads such as Azure, Office 365 or other integrated apps in Azure Active Directory. I like to give a detailed overview about data sources or signals that should be considered for monitoring based on identity-related activities, risk detections, alerts and events across the Microsoft ecosystem.

Table of Content:

Identity Security Monitoring in a Hybrid Environment

In the recent year, I‘ve talked about monitoring of Azure Active Directory in community sessions and talks. From my point of view a comprehensive monitoring of identity security events must be an essential part of deployment plans and daily operations. Even though it may seem obvious as "best practice" ("Actively monitor for suspicious activities"), it is sometimes underrated.

Monitoring across "Azure AD" and "Active Directory" (including spreading between workloads in Azure and on-premises environments) can be complex and sometimes challenging but more important then ever. Identity protection in a "hybrid world" means also to protect and monitor Active Directory environments with all existing risks and traditional attack methods (e.g. "Pass-the-Hash"). The weakest link and uncover attack surfaces in your on-premises environment can be used to leverage or extend attacks to (hybrid) cloud services.

./media/identity-monitoring/AzIdentity_Security.png "Microsoft Defender for Identity" (MDI), "Microsoft Defender for Cloud Apps" (MDA) and "Azure AD Identity Protection" (IPC) protects identities on various levels and platforms (On-Premises, Session/Cloud Apps and Cloud Identity/Sign-ins)

Implementing "identity security" does not end with "enabling" those features or by following the recommendations by "Identity Secure Score".

It’s important to develop a "continuous improvement" strategy of detections and "operational guide" to empower and monitor your signals of "guards". This includes also to provide workflows for automated response, an "unified view" for incident management/hunting, security processes and posture management. In addition, Microsoft products are being continuously improved and also changes in integration and connection between the products needs to be considered.

Extensive possibilities of "User and Entity Behavior Analytics" (UEBA) allows SecOps to find anomalous activities (calculated by machine learning algorithms) across the various data sources or signals instead of building a manual correlation.

As always, keep up-to-date and notified about latest changes of security features, attack/defense scenarios or security recommendations. Verification of effectiveness by "simulated attacks" should be also part of your operational tasks.

Changes of product names and portals

Note: Microsoft announced many product name changes at the Ignite 2020 and Ignite 2021. I've used all new product names in this article. A good overview of all name changes are included in this blog post by Microsoft.

In addition, the Microsoft 365 Defender (M365D) Portal has been become the unified portal for all M365 products:

Previous product name New product name Previous portal URL New portal URL Migration to Unified M365 Security Portal
Azure ATP (AATP) Microsoft Defender for Identity (MDI) https://TenantName.atp.azure.com https://security.microsoft.com Alerts and Configuration in M365D Security Portal (Redirect to new portal can be configured)
Azure Security Center (ASC) Microsoft Defender for Cloud (MDC) https://portal.azure.com https://portal.azure.com No integration planned
Azure Sentinel Microsoft Sentinel https://portal.azure.com https://portal.azure.com No integration planned
Azure Defender Microsoft Defender for Cloud (MDC) https://portal.azure.com https://portal.azure.com No integration planned
Microsoft Cloud App Security (MCAS) Microsoft Defender for Cloud Apps (MDA) https://TenantName.portal.cloudappsecurity.com https://security.microsoft.com Alerts and Configuration in M365D Portal (security.microsoft.com)
Microsoft Defender ATP (MDATP) Microsoft Defender for Endpoint (MDE) https://securitycenter.windows.com/ https://security.microsoft.com Alerts and Configuration in M365D Portal (Redirect to new portal can be configured)
Office ATP (OATP) Microsoft Defender for Office (MDO) https://protection.office.com/ https://security.microsoft.com Incidents and Configuration in M365D Portal (Redirect to new portal can be configured)

Scope of documentation and side notes

This article is an attempt to give a detailed overview on solutions to collect identity-related security events and implement auto-response on threads or risks. Many links to detailed documentation by Microsoft and members of the community are included. There is no claim for completeness and comprehensive view of all options. I've tried to find some "sample use cases" to underline when this monitoring option will be in particularly relevance. It was hard for me to find the right level of details or scope with regard to the wide-range of this topic.

The following objectives are excluded and out of scope: Azure AD B2C, Azure AD Domain Services and Microsoft Information Protection (AIP/MIP) will not be described in this blog post.

Caution: All description of features, potential limitations and implementation considerations are based on personal experiences and research results at the time of writing this article. Therefore the content and statement can be outdated since the article was published.

Tip: The following visualization are showing flows of incident/alert and raw log data but also integration between different Microsoft Security products. Therefore I've used different lines and colors which makes it easier to identify

Legend

Tip: Verify and evaluate your implemented solutions and detections in a simulation of common attack scenarios to Azure AD. Incident response playbooks and the attack/defense scenarios from the community-driven "Azure AD Playbook" project are offering detailed guidance and considerations for attack simulations.

Azure Monitor: Operational Logs and Alerts of Azure AD and Azure Workloads

Sample use case: Security Operation Teams (SecOps) manages Microsoft Azure workloads only (no M365 services) and needs an "unified view" of Azure Services and Azure AD security events. No hybrid identity (Windows Server Active Directory) or hybrid cloud (Google Cloud, AWS) scenarios.

./media/identity-monitoring/AzIdentity_AzMonitor.png

Data Sources of "Azure Monitor Logs"

IaaS/PaaS (Cloud and on-Premises) in "Azure Monitor"

Azure Monitor allows you to collect logs from the Azure platform and resources for visualization and alerting or forwarding to other destination (for long-term retention or advanced scenarios). In this use case we are using Microsoft "Log Analytics" to enable advanced (KQL-based) queries and centralized collection of logs. The following data sources should be considered to collect relevant information for your IAM security monitoring:

Microsoft Defender for Cloud and "Azure Monitor"

Formely known as: Azure Security Center (ASC)

Continous Export allows to forward alerts and recommendations to "Azure Event Hub" or "Log Analytics". This solution was divided in two different scopes in the past: Free service "Security Center" as "Cloud security posture management (CSPM)" solution. Azure Defender as "Cloud workload protection (CWP)" add-on with licensing option to pay only for what you use. Both solutions are rebranded under the product name "Microsoft Defender for Cloud".

Cloud Identity (Azure Active Directory) in "Azure Monitor"

Routing of Azure AD activity logs is natively supported to various targets such as Azure Event Hub, Blob Storage and Log Analytics.

  • Supported reports in Azure Monitor (GA):

  • Microsoft updated the logging capabilities in Azure AD as addition to the above mentioned classic "Azure AD Reports".

    • "Non-interactive user" sign-ins: Sign-in events which do not require the user to provide an authentication factor. A client app or devices uses a token or code in background of the user's activity to authenticate or access a resource.
    • "Service Principal" sign-ins: An app or service (with Application Identity) authenticates by using own credential to access resources.
    • "Managed identity" for Azure resource sign-ins: Sign-ins performed by Azure-managed resource(s) with assigned to user- or system-assigned managed identity.

  • Azure AD Identity Protection Security Logs: Identity Protection of Azure AD Premium stores reports and events of risky users, sign-ins (up to 30 days) and detections (up to 90 days). Also signals from other products (e.g. MDE detection of "Possible attempt to access PRT") are stored in the risk events. Diagnostic settings support for exporting Identity Protection data is available for users and workload identities. KQL-based queries and custom alerting can be executed on the following categories and log tables:

    • AADRiskyUsers (report of risky users)

    • AADUserRiskEvents (risk detections of users)

    • AADRiskyServicePrincipals (report of risky workload identities)

    • AADServicePrincipalRiskEvents (risk detections of workload identities)

    • In general, various "risk detections" are available in Identity Protection which will be calculated in real-time or offline. Risk state triggers "auto-response actions" and offers "self-remediation options" that will be managed by identity protection policies or as part of Conditional Access Policies.

    • Microsoft Graph APIs allows you to collect this data for export or automate response to risk detections.

    • Every Azure AD Sign-in log includes the following properties related to the identity risk detection: riskDetail, riskLevelAggregated, riskLevelDuringSignIn, riskState, riskEventTypes.

      ./media/identity-monitoring/AzIdentity_AzMonitor_IPCDetection.png Risk detections from "Defender for Cloud Apps" (such as "Impossible Travel") will be also displayed in the "Identity Protection" blade (Azure portal). Correlation between sign-in event and offline detections by Identity Protection (in this sample "Password Spray, Malicious IP address and Atypical travel) can be established by Request or CorrelationID.

      ./media/identity-monitoring/AzIdentity_AzMonitor_IPCQuery.png Collected "sign-in events" in "Azure Monitor Logs" will be enriched with "RiskState" and "RiskLevelDuringSign" if a risky sign-in was detected (in real-time or sign-in attempt was made after risk detection).

Log Collection (via "Azure Monitor")

  • Log Analytics: Azure's native "Log Management Solution" enables deep analytics and advanced queries in case of troubleshooting or technical investigation. Kusto (KQL) is the query language that you should use (and learn). This is the foundation of many features and primary query language in solutions such as as "Microsoft Sentinel" (built on top of Log Analytics) or "Azure AD Workbooks" (sourced log data from a workspace). Other monitoring solutions in the "Azure platform" are using also "Log Analytics workspaces" to store data (e.g. App Insights).

Analyze and Visualize with "Azure Monitor"

  • Azure AD Workbooks: Microsoft provides built-in visualization which requires Log Analytics workspace. They are very helpful to analyze (and troubleshoot) activities around Authentication, Conditional Access, Sign-in health, Sensitive Operations of Service Principals/Authentication Methods and other identity-related operations.
  • Azure AD Dashboards: Azure AD Dashboard views are available for "Account Provisioning" and "Sign-In Events" but seems little bit outdated.
  • Usage and Insights: An overview about registered/usage of "authentication methods" and "Azure AD-integrated apps" activity are available in the "Azure Portal". These usage statistics are also available via "Microsoft Graph API". The following sample script analyse the statistics to make recommendations.
  • Log Analytics Solutions:
    • AD Health Check: Optimize your Active Directory environment with the "Active Directory Health Check" solution in Azure Monitor
    • AD Replication Status: Monitor your "Active Directory replication status" with Azure Monitor
  • Azure Security Benchmark Workbook: Visualization of data collected by Microsoft Defender for Cloud to check compliance status in alignment with the Azure Security Benchmark (ASB). This contains also security controls regarding Identity Management and Privileged Access in Azure.

Integration and Response in "Azure Monitor"

Considerations and References of Azure AD Logging by "Azure Monitor"

  • It's very important to have a deep understanding of the Azure AD architecture to cover all components for security monitoring. Microsoft has released an architecture description which gives a good overview of Azure AD for SecOps Teams.
  • Microsoft has published an "SecOps Guide" for Azure AD which offers an overview of many identity security configuration and what should be monitored. This includes query samples, source of logs and notes on detections.
  • "Deployment guide of Azure AD Monitoring” from Microsoft gives you an general overview of aspects and options to integrate or archive logs. The latency of Azure AD logging and the risk detections should be also considered (for your security response and processes).
  • Follow steps on the Microsoft Defender for Cloud Enterprise Onboarding Guide to identify requirements, recommendations and deployment tasks.
  • Retention of the reports depends on type of activity and your Azure AD license.
  • Costs should be calculated based on the requirements for long-term retention.
  • Pay attention to missing audit logs of privileged activities in Azure Monitor.
  • Rate limitation of "Azure Alerts" should be considered for your service emergency and operational notifications.
  • Identity Protection provides APIs to get events and risk status of your users.
  • I can strongly recommended to test and validate the detection mechanism in "Identity Protection" (as described in the blog post by Sami Lampuu). Take care on the delay and latency between attack and detection of the various mechanism. Keep in mind, risk response (as part of the "Risk Policies") must be in accord with your Azure AD implementation.
    • Example: Force password change by risky sign-in detection works only in hybrid environments if password write-back is allowed.
  • Consider the limitations and behavior of "Identity Protection and External Users (B2B Guests)"
  • Hybrid identity environment: Collect and monitor logs from "Azure AD Connect" servers and the "Password Hash Sync" agent.
  • You might be facing the follow considerations in your daily work experiences:
    • Name in reports are based on the object name at the time of the event/sign-in
    • B2B users are able to get "user insights” and therefore internal information
    • Users can review the sign-in history as part of the "My-Sign-Ins" portal and give feedback on suspicious activities ("This wasn't me" option).
    • Non-Global Admins can access logs
      • Security Administrator & Reader
      • Reports Reader and Application Administrator
      • Global Reader
  • Microsoft "Identity Secure Score" is recommended for regular check as part of your (cloud) "identity security posture management" and can be integrated in your monitoring via Security Graph API.
  • Customer-managed keys can be configured and are supported for encryption in "Azure Monitor".
  • Self-Service Password Reset (SSPR): Monitor blocked attempts or suspicious activity via Azure Monitor Alerts or Microsoft Sentinel
  • Consider service principal logs and the challenges to build relation to "Azure Activity" or "(Azure) DevOps Deployment pipeline" logs, as described in my previous blog post!
  • Currently, there are four different "Windows Agents" for Azure Monitor available. Read the Microsoft Docs article to get an overview of the various Azure Monitor agents. The "new" Azure Monitor agent (AMA) is "General Available" (GA) and will be the consolidated solution. Consider that previous/legacy agents will be deprecated. Keep in mind to migrate your integrations to the "new" Azure Monitor Agent until August 31, 2024 (End-of-support for Log Analytics Agent)
  • Marius Sandbu has written an excellent "deep dive" article about "Azure Monitor" and "Log Analytics" which is strongly recommended to read for a good understanding of the architecture.

MDA and "Defender for Identity": Unified SecOps of connected "Cloud Apps" and "Hybrid Identity"

./media/identity-monitoring/AzIdentity_MDA.png

Sample use case: SecOps that manages security of cloud platforms or SaaS solutions and need an unified view for investigation or alerting on (hybrid) identities.

Data Sources in Microsoft Defender for Cloud Apps (MDA)

IaaS/PaaS (Cloud and on-Premises) in MDA

MDA allows you to connect Microsoft‘s Azure platform and other cloud platform provider (AWS and Google Cloud Platform) via "App Connector". This makes "Activity logs" available in MDA for investigation and trigger alerts. The security configuration of "Google Cloud" and "Amazon Web Services" (AWS) can be integrated to provide fundamental security recommendations based on the CIS benchmark.

Microsoft Defender for Cloud and MDA-Integration

Security Configuration Assessment results of MDA will be collected from "Microsoft Defender for Cloud". This gives you a common view of the security posture, usage of cloud resources and suspicious activities across your cloud infrastructure assets (in Microsoft Azure).

Side note: It's strongly recommended to have a look on the Multi-Cloud Posture Management features in "Microsoft Defender for Cloud" (MDC) to integrate 3rd Party Cloud providers (AWS, Google Cloud). There are a couple of benefits to use the Azure Portal and MDC for review of security configuration and assessments

Cloud Identity in MDA

*Azure AD audit and sign-in events are covered by the "Office 365 connector" in MDA. But only interactive sign-in activities and sign-in activities from legacy protocols seems to be included.

Advanced categories such as "Service Principals" aren't covered by the connector.*

  • Severity of (cloud) identity risk alerts can be managed by MDA integration of "AAD Identity Protection".
  • Detections of "Identity Protection" are part of the UEBA/investigation priority score and will be also displayed on the user page.

./media/identity-monitoring/AzIdentity_MDA_IPCAlerts.png "Identity Protection" risk detections will be listed in the MDA alerts view.

On-Premises Identity (Active Directory) in MDA

Microsoft Defender for Identity (MDI) allows you to detect and identify attacks in your "on-premises environment". It‘s based on monitoring and profiling of user behavior and activities. MDI includes the detection of Lateral Movement Paths (LMP) which is strongly recommended to consider. Keep in mind, machine-learning on user/entity-related behavioral needs a learning period.

  • Security Alerts are categorized in phases of the "CyberAttack kill-chain" and are well documented by Microsoft.

  • Remediation actions allows disable, suspend or reset passwords of user in Active Directory. It's recommended to create a gMSA account as action accounts.

  • Integration of MDI with MDA is mandatory for environments where both solutions are in use. More and more features around MDI seems to be moved to the MDA portal (such as the new "hunting experiences"). All activities and detections of MDI will be also included in the UEBA if integration is configured.

    ./media/identity-monitoring/AzIdentity_MDA_MDIPortal.png Attacks on Active Directory (On-Premises) will be detected by MDI and generates an alert. This screenshots shows the alert in the legacy MDI ("Azure ATP") portal.

    ./media/identity-monitoring/AzIdentity_MDA_MDIAlertInMDA.png In the recent years, Microsoft has been implemented a "new" hunting experience which allows to use MDA portal for unified incident management between "Active Directory" and "Azure AD" alerts.

    • MDA is using MDI data as source to collect activities from Active Directory as an "app". This gives you an "unified activity" overview of an user in "Azure AD", "Active Directory" and "MDA connected apps". ./media/identity-monitoring/AzIdentity_MDA_UnifiedFailedLogins.png Example: Failed sign-in attempts to Active Directory or connected apps (in this case, "Azure Portal" and "Office 365").

  • All alerts and events of MDI can be exported in CEF format.

  • Regular updates on detections includes improvements of existing capabilties but also adding new detection methods that raised up. A good example was the vulnerability detection of ZeroLogon in November 2020.

  • Details on managing and investigation are very well documented in a TechCommunity blog article about "daily operation of MDI". Another article in this series describes details on "Deployment and Troubleshooting".

Cloud Session Monitoring by MDA

Microsoft Cloud Access Security Broker (CASB) enables you to identify usage of cloud apps, insights of risk assessments and capabilities to control the sessions and access to the cloud apps. There are some features that are essential for monitoring your identities and their access to sanctioned or unsanctioned resources or apps:

./media/identity-monitoring/AzIdentity_MDA_CloudSessionAlerts.png MDA allows to get insights of suspicious user behavior in the session to a connected cloud app (such as download/upload to OneDrive and SharePoint). Custom activity alerts are also possible (like in this example, activity by "Global Admin to gain elevated access to Azure Management scope").

Collaboration Platforms (Office 365 Services) in MDA

Microsoft‘s Office 365 but also other collaboration platforms (Dropbox and G-Suite) or SaaS provider can be connected via "app connectors". This gives you options to visibility, governance and protection of those services. Level of centralized management in MDA depends on abilities that are supported by the connector.

  • App Connector of "Office 365" will be also used to source the following "Azure AD" information and are prerequisites for the identity monitoring capabilities in MDA:
    • Azure AD Users and groups (Meta information of those objects in the tenant)
    • Azure AD Management events (Audit Logs)
    • Sign-in events (Interactive Sign-in activities and activities from legacy protocols such as ActiveSync)
    • Azure AD Apps (registered "OAuth" apps)
  • Audit data will be ingested from the "Office 365 Management Activity API". A deep dive description of collecting this audit events are very well described in a blog post by Sami Lamppu. In general, the audit log from "Office 365 Security and Compliance Portal" shows the same level of information as the activity log from the MDA "app connector".
  • Alerts of "Microsoft Defender for Office 365" (MDO) are also visible in the "MDA Activity Log" and allows you to create custom policies in MDA. Sami Lamppu has also given some details about this in one of his blog posts.

Device / Endpoint Security (Microsoft Defender for Endpoint) Integration in MDA

"Microsoft Defender ATP" (MDATP) Portal was rebranded to "Microsoft Defender Security Portal" in the fall of 2020. Microsoft's Endpoint and Detection and Response (EDR) solution allows deep integration to MDA. But also insights from MDA will be displayed in the (new) Endpoint Security Portal.

Signal forwarding from "Microsoft Defender for Endpoint" (MDE) to MDA is an essential configuration to establish the visibility of "cloud app usage" and control of unwanted apps (as described previously). But it's also extend the "MDA Discovery Dashboard" with an additional "machine-centric" view. This allows you to start investigation based on a specific machine and correlate statistics of risky apps, transaction/traffic and device risk (calculated by MDE) right from MDA. A direct (deep) link to the machine object helps to continue the investigation in the "Microsoft Defender Security Center" (MDE Portal).

Analyze and Visualize with MDA

User and Entity Behavior Analytics (UEBA) in MDA

  • (Hybrid) Identity Threat Investigation: The "user page" in MDA gives you an overview and correlated information from all connected apps or integrated "threat protection solutions" in a single view. This is also a landing page to get all related and collected information about activities (from the "Activity Log"), alerts (filtered by selected user) or actions by policies ("Governance Log"). User Exposure information shows summary from various sources (e.g. number of accounts that are correlated by app connector). Activities of the users can be filtered and will be enriched by MDA (such as Internal/External users, Status as admin account or critical role/group assignment).

    • User page and "hunting experiences" in "Microsoft Defender for Identity" will be probably moved to the MDA portal.
    • Device page is also available for all MDI device objects and shows open alerts and summary of activities (logged on users, resource access, IPs)

  • Investigation Priority Score: This score helps to identify the riskiest users across the various signals, alerts and integrations. Therefore, the "Investigation Priority" pulls together signals from connected apps and integrated threat protections (MDI and "Azure AD Identity Protection") to find abnormal behavior and aggregate this into a single score value. This score will be displayed on the "MDA dashboard" and in the user page for further investigation.

    • Matt Soseman has recorded a YouTube video about it which includes the calculation of the score and some demo on investigation in the "UEBA".
    • Consider to tune the policies for anomaly detection and review the default governance actions after enabling the data sources (threat protections, connected apps and discovery logs).

    ./media/identity-monitoring/AzIdentity_MDA_UEBA.png Alerts and activities of the last 7 days will be shown in the user page only. "Investigation priority" only considered the threats within this time range. So keep in mind, the total number of "open alerts" in the "user threat" panel.

Identity Security Posture and Apps Inventory with MDA

Integration and Responds in MDA

  • Policies: Control of your identities in connected apps/resources can be achieved by monitored activities and signals by MDA. The following types of policies can be configured:

    • Access Policies gives you the ability for real-time monitoring and control the access on your "connected apps". The applied actions ("Monitor" or "Block") can be filtered on advanced criteria such as device tags, source of access (IP address), client app or user/app scope.
    • Session Policies enables real-time action and monitoring within the session and allows to block or restrict on specific activities (such as sharing or file control).
    • Activity Policies enforces automated response on a specific or repeated activity to a connected app. As a response, governance actions can enforce security mechanism on API level by "connected app" (e.g. require sign-in prompt in Office 365), user account state in Azure AD (e.g. disable user) or custom playbook (PowerAutomate). Activities of tasks that is performed by a user or admin of your Azure AD tenant.
    • Anomaly Detection Policies are enabled to find unusual activities and trigger an alert if unusual behavior was detected (different from user's regular activity). They are part of the UEBA and ML capabilities which are integrated in MDA and displayed in the "User Page" / "Investigation Priority Score". Built-in policies covers activities from specific activities in a connected app (e.g. connected "Azure Instance" and "Multiple delete VM activities") to find anomalies of a single user session ("Unusual activities by user"). Some anomaly detection policies can be tuned or scoped to adjust sensitivity or customize automated response.

    ./media/identity-monitoring/AzIdentity_MDA_Governance.png Governance log shows actions (initiated by policies) of automated response on alerts (such as require user to sign-in again if a risky sign-in was detected).

  • Policy Templates: Before creating your own policies, check the built-in templates in MDA that are ready for use. Many of them are essential and strongly recommended to be enabled and configured in your MDA instance.

  • PowerAutomate: Automation of (governance) actions can be realized by "PowerAutomate". Microsoft has released some sample playbooks for auto-remediation or -response scenarios on GitHub.

Considerations and References of "Defender for Cloud Apps"

  • Interaction, integration and options of MDA with other services in "Microsoft 365" are numerous and plays a significant role. Check out MDA design diagram (by ManagedSentinel.com) to get an overview of those connections.
  • Regular check of "MDA Changelog" should be made to be informed about changes in your tenant and new features or risk detection.
  • MDA allows to gain sensitive information about a user which includes files, used cloud apps and all activity logs from connected apps. Therefore you should verify with your "IT Compliance and Data Privacy Department" if anonymizing of user data is required (to protect user privacy). Currently this feature is limited to user and machine names.
  • "MDA status page" has been deprecated on April 29th, 2021. Service health of MDA should be monitored with the Service Health Dashboard (part of the M365 Admin Portal). Make sure you get notifications of service issues or delays of detections
  • Consider Microsoft's best practices of implementing MDA in your environment
  • Governance Actions (by activity policies) must be in accord with your Azure AD environment.
    • Example: Suspended user will be reactivated after next Azure AD Connect sync interval.
  • MDA API can be easily discovered and tested by using the postman collection (from Rich Lilly).
  • Office 365 App Connector needs at least one assigned licensed user even if you want to use it to collect all Azure AD events only.
  • Implement a process and simulate investigation of anomaly detection alerts!
  • MDA is very useful and efficient to monitor suspicious privileged tasks in Azure.
    • Elevated Global Admin permissions on Azure Management (as already mentioned in the sample) is one of the use cases which can be (as far as I know) only be monitored by MDA. Sami Lamppu has written a detailed blog post about it!
  • RBAC in MDA doesn't allow assignment of roles to Azure AD groups (only users are supported).
  • Scoped deployment can be very useful in setting up "Proof-of-Concept" environment or staged roll-outs in production
  • Currently, blocking access to Cloud apps by (custom) indicators in "Microsoft Defender for Endpoint" (MDE) has some limitations:
    • MDE allows 15.000 indicators per tenant
    • This feature is supported on Windows 10 only (no support for ATP on MacOS or Linux yet)
  • Detailed training on MDA features is available for self-study as "Ninja Training"
  • Overview of APIs and best practices in using them are described in a TechCommunity blog post

Considerations and References of Microsoft Defender for Identity (MDI)

  • Microsoft has published a Ninja Training for MDI which gives you a good overview about features and detections
  • Check alerts for false-positive events ("DCSync Attack") of "Azure AD Connect" server (exclude them for this specific detection).
  • Signature-based capabilities can be evaluated as part of the "Defender for Identity security alert lab". Simulation of "Lateral Movement Attacks" is recommended and described in a blog post (by Derk van der Woude) and also in a blog post by Jeffrey Appel.
  • By default, some domains are excluded from detections (Example: spotify.com)!
  • Audit Policy of domain controllers must be configured to maximize detection capabilities. Using this PowerShell script should helps you to verify the configuration.
  • Review the known issues and limitations of MDI sensors and detections
  • Currently there seems no option to collect Sensor health status out of the box for operational monitoring.
  • Global and Security Administrator are assigned with MDI "Administrator" permission by design. Default "Azure AD security groups" ("Azure ATP Administrator/Users/Viewers") can be used to delegate permissions on the MDI RBAC model. Modification of those group membership should be monitored for prevention of access to security sensitive logs or disabling the sensor/detection.
  • I can only recommend to review the list of "sensitive accounts and groups" and add non-builtin privileged objects (e.g. hybrid identity components such as "Azure AD Connect" and the service accounts).
  • Subscribe the RSS feed of "What's new" to be notified about product changes and new features
  • Microsoft 365 Defender allows to write KQL queries and custom detections based on MDI data. There are some interesting use cases in enhancing this data. Keep in mind, the onboarding and integration of MDA and MDI is still required and one of the pre-requisites.
  • Service health can be monitored on the MDI status page and integrated for notification of service issues or delays of detections. Consider to actively monitor the sensors in your infrastructure.
  • Sizing tool and capacity planing guidance of MDI should be used in the planning phase to calculate amount of traffic, supportability and resource recommendations for sensors.

Microsoft 365 Defender: Unified SecOps of M365 Services

Sample use case: SecOps needs a unified visibility of logs and possibility of hunting across all "Microsoft 365" services and assets (data, identity, endpoints and cloud apps). Consolidated view on logs and summarized incidents from all "M365 Defender" services with enriched data is needed. Using centralized investigation of recorded activities (telemetry) in M365 services and empowering built-in (auto)-remediation of incidents by "Automated Investigation and Response (AIR) System".

./media/identity-monitoring/AzIdentity_AzMonitor.png

Microsoft 365 Defender (formerly "Microsoft Threat Protection") supports various services from the "M365 platform". Check the "supported services" list to understand which data sources can be integrated. Start using "M365 Defender" is very easy by "turn on" the described setting in the "Microsoft 365 Security Center".

Note: Microsoft 365 Defender becomes the unified security portal for all Defender products. Nearly all features and options are available in the new security portal. Microsoft offers images and tables to shows the changes between the navigation in the MDA and the M365D portal.

Data Sources in "M365 Defender"

IaaS/PaaS (Cloud and on-Premises) and "M365 Defender"

Azure resource-level or collected logs by Azure Monitor are not covered by "M365 Defender". Example: Event logs of Azure/Hybrid Servers or alerts from Microsoft Defender for Cloud are not visible for hunting in this portal. Nevertheless, Azure Activity Logs are part of the "CloudAppEvents" table if the App Connector to "Microsoft Azure" has been enabled in MDA.

Cloud Identity (Azure Active Directory) in "M365 Defender"

  • Incidents / AlertInfo: All risk detections from "Azure AD Identity Protection" can be ingested as Alert (incl. correlation as "Incident") to the advanced hunting table AlertInfo" as part of the IPC integration in M365 Defender.

    • MDA feeds the configured (integration) type of alerts to "M365 Defender". MDA will be named as "ServiceSource" and "DetectionSource" for all IPC risk detections which has been detected by MDA. Microsoft has been integrated all identity alerts from Identity Protection to the unified security portal. This includes alerts which has been detected by MDA and IPC natively: ./media/identity-monitoring/AzIdentity_M365D_IdentityAlerts.png
    • "Azure ID IP Alert Settings" in the alert blade of M365D Portal allows you to define the level of integration and scope. ./media/identity-monitoring/AzIdentity_M365D_IPCSettings.png

  • IdentityInfo: Account information from various identity sources (including "Active Directory" and "Azure AD") will be stored here, to enable build relation between user objects (e.g. ObjectID, "On-Premises SID" and "Cloud SID"). Other details such as DisplayName, ProxyAddress or Account Status are also included.

  • IdentityLogonEvents: Authentication events captured by MDA will be stored in this table. This seems to covers only "sign-in events" to connected apps and are similar to the "Activity Logs" in the MDA blade (filtered by "Successful or failed login-ins"). As already described, "non-interactive" logons or sign-ins by "service principal"/"managed identity" are not included in this table yet.

  • Hunt for Azure Active Directory sign-in events: Microsoft added the following tables to analyze interactive and non-interactive sign-ins. Both tables are being offered on "short-term" basis and will be eventually move to the IdentityLogonEvents table:

  • AADSpnSignInEventsBeta: Information about sign-ins from "Service Principals" and "Managed Identity" will be stored in this table. This feature is in "beta".

  • AADSignInEventsBeta: Interactive and non-interactive user sign-ins are available from this table.

  • CloudAppEvents: This table contains all streamed logs from the "Office 365 connector" in MDA which includes the audit logs from "Azure AD" (in public preview) as well. It seems that Azure AD logon events are not included.

On-Premises Identity (Active Directory) in "M365 Defender"

It's important to know that data of "Microsoft Defender for Identity" (MDI) will only be shown in the "M365 Defender" portal if the integration between MDA and MDI is enabled. MDA seems to be responsible to feeds the related MDI data to "M365 Defender".

Correlation of MDI alerts with other activities and alerts from "M365 Defender" services (such as "Microsoft Defender for Endpoint") gives you new capabilities to understand the context of Active Directory attacks. This becomes obvious if you think about the limited visibility of endpoint (threats) in MDA. ./media/identity-monitoring/AzIdentity_MDI_M365DAlert.png The previous showed example of a brute-force attack will be also shown as alert in M365D including Alert graph and MITRE ATT&CK TTP mapping.

./media/identity-monitoring/AzIdentity_MDI_M365D.png

But the alert will be also shown as incident and correlated with other alerts (if applicable) as multi-stage attack.

Recently, Microsoft added the opportunity to use "Advanced Hunting" based on events captured by MDI. Another benefit (compared to MDI queries in the MDA portal): Writing KQL queries for advanced hunting in "M365 Security Portal" by using the advanced logs from the following tables:

  • AlertInfo: Alerts from MDI will be stored in this table. AlertId includes the prefix "aa" (stands for Azure ATP?) followed by the original "AlertId" from the MDI portal (not the MDA AlertID!).

  • IdentityInfo: As already described before, this table helps to correlate and build relation between various account objects. In this case, very helpful for advanced hunting and queries between "Azure AD" and "Active Directory" user objects.

  • IdentityLogonEvents: Authentication events to your "Active Directory" will be stored in this table. The logon events will be sourced from the connected MDI instance in MDA and shows similar results to a filtered "Activity Log" (by "Active Directory" app in the MDA portal). Various types of logon events in "Active Directory" are covered (including Remote Desktop, Interactive and Credentials validation via NTLM/Kerberos). Failure reason of "sign-in attempts" are also included (e.g. OldPassword).

  • IdentityQueryEvents: Queries on Active Directory objects (such as LDAP, DNS and SAMR) are collected from MDI in this table.

  • IdentityDirectoryEvents: This table contains many identity-related (on-premises) audit and system events from the domain controller. User-level auditing of password or group memberships are included but also "domain controller events" such as PowerShell execution, Task scheduling or potential lateral movement.

Cloud Sessions (Microsoft Defender for Cloud Apps) in "M365 Security"

Cloud Discovery and activity logs from connected apps are not available for hunting in "M365 Defender".

  • DeviceNetworkEvents: As already described, "Microsoft Defender for Endpoints" (MDE) can be configured to forward signals to MDA (for "Cloud Discovery" and "Visibility of (un)sanctioned cloud apps"). This table helps to start queries on the raw logs from MDE.

Collaboration Platforms (Office 365 Services)

  • AlertInfo: Threat protection signals and data will be correlated from "Microsoft Defender for Office 365" (MDO) in M365 Defender. But it's limited to features and alerts around "Exchange Online" (such as "Safe Links" or Attachments).

Other Exchange Online-related logs and events are stored in the following tables and could be relevant for hunting of phishing mails:

Note: Interested in MDO? A great overview of the threat protection features for Office 365 is given by a deep dive blog post from Kenneth van Surksum.

Device / Endpoint Security (Microsoft Defender for Endpoint) and "M365 Defender"

Integration of "Microsoft Defender for Endpoint" (MDE) enables visibility on endpoint states, raw events, detections and alerts (which includes EDR/AV/attack surface reduction) and entities related to devices in M365 Defender.

  • AlertInfo: Alerts from MDE will be shown in this table. Other events from this source will be stored in the following tables:

  • DeviceEvents (security controls such as AV or Exploit protection)

  • DeviceLogonEvents (logon events on/to devices from local or (Azure) AD users)

  • DeviceInfo (similar to the approach of the table "IdentityInfo", helps to correlate or build relation based on meta information by devices)

M365 Defender provides a "Device profile page" which is accessible from the "Incident" view. This gives you a unified control on M365 Defender- and MDE-related actions.

Analyze and Visualize with "M365 Defender"

Monitoring and Reporting ("Cards" in M365 Security Home)

Dashboard of "Microsoft 365 Security Center" allows to add "cards" for summarized reports of various sections of security areas in "M365 Defender" (including "identity monitoring and reporting").

Investigation of Incidents in "M365 Defender"

Incidents can be managed in the portal by adding comments, adjusting priority, reporting false/positives or checking related entities (devices/users) or alerts.

Suspicious entities are also stored in the table "AlertEvidence" which can be used for custom queries or advanced hunting.

Advanced Hunting in "M365 Defender"

As already described, "M365 Defender" supports hunting on query-based analytics (KQL) across the various tables from supported M365 services. This allows you easily to start hunting between activities and alerts of devices, e-mails and identities.

Custom Detections with "M365 Defender"

Advanced Hunting queries can be used to create a "Detection Rule" for alerting. This gives you the ability to proactively monitor specific critical events or potential threats. Applicable actions can be triggered if an entity is founded in the query (for example: Isolate device in case of a "Brute Force" attack).

Integration and Response in "M365 Defender"

Auto-Investigation and Response (AIR)

M365 Defender supports remediation actions on suspicious or malicious "Devices", "Files" and "Emails" but also manual actions on "Users" (incl. confirm as compromised). Pending (if approval is needed/configured) or completed actions are visible and can be managed in the "Action Center". This incident response activities follows after an automated investigation by M365 Defender.

Automation level and scope for Endpoints can be configured in the "Microsoft Defender Security Center" (MDE Portal). Policies for Office 365 can be configured in the "M365 Security Center".

Threat Experts

Advice by Microsoft's Threat Experts can be requested directly from the "Incident" view. This is an additional service which can be enrolled for a 90-day-trial or on-Demand subscription (by Microsoft).

Considerations and References of "M365 Defender"

Microsoft Sentinel: "Single pane of glass” across Azure, Microsoft 365 and 3rd party (cloud) platforms

Sample use case: SecOps that needs a visibility across all "Microsoft Cloud services" (Azure and M365) and (Hybrid/On-Premises) infrastructure. Extended possibilities for customization of auto-response, integration of "3rd party security tools" or implementation custom detections are required. Microsoft Sentinel empowers SIEM capabilities as part of a cloud-native and integrated security solution by Microsoft. Longer data retention of logs and alerts, out-of-the-box detections and visualization are further advantages.

./media/identity-monitoring/AzIdentity_AzSentinel.png Microsoft 365 Defender Incidents can be fully integrated with Microsoft Sentinel and offers a bi-directional sync. The unified connector will replace the previous single connector for MDE, MDI, MDO and MDA. In addition, advanced hunting tables can be ingested to Microsoft Sentinel.

Data Sources of "Microsoft Sentinel"

All of the following data sources can be connected to "Microsoft Sentinel" by data connectors. Alerts from the Microsoft Security products can be created as "Incident" automatically or offering already an incident creation by the data connector (e.g. M365 Defender Unified Connector). Incidents generated by this products will be stored in the "SecurityIncident" table of the workspace.

Most of the following features can be used to visualize or extend the logs and alerts from data sources:

Note: Most of the KQL queries and dashboards are already integrated as "Templates" and available in your instance (right after the deployment). Nevertheless, I have added the links to the GitHub repository where you can find the original source of the templates.

Note: Microsoft has published a unified "Microsoft 365 Defender" connector which allows one-click ingestion of all incidents (alerts and entities) from the M365 Security Portal into Microsoft Sentinel. Furthermore the new connector allows bi-directional sync and streaming of all relevant information (advanced hunting tables) to Microsoft Sentinel. Detailed information about the integration of M365 Defender and Microsoft Sentinel are available in Microsoft Docs. Consider side effects of duplicated incidents if both connector (component alert connector of single M365 Defender services and the unified M365 Data Connector) are enabled at the same time. The new connector improves the integration between Microsoft Sentinel and M365D by a seamless experience for responding to security threats for SecOps. Streaming (mostly all) advanced hunting event collection from M365D to Microsoft Sentinel is another great benefit.

IaaS/PaaS (Cloud and on-Premises) in "Microsoft Sentinel"

Microsoft Sentinel is built and will be deployed on "top of" Log Analytics Workspaces. Collection of security and audit logs from "Azure Resources" or servers (On-Premises or hosted by "3rd Party Cloud Providers") can be implemented, alongside of the previously described "Azure Monitor (Logs)" integration. Microsoft Sentinel offers some "data connectors" to easily integrate the following data sources:

Microsoft Defender for Cloud and Microsoft Sentinel

Alert Data from Microsoft Defender for Cloud: This connector allows to ingest alerts of detected threats by MDC. The alerts will be found in the "SecurityAlert" table as ProviderName "Azure Security Center".

Cloud Identity (Azure Active Directory) in "Microsoft Sentinel"

Data from Azure AD Logs: Data connector is configuring and using "diagnostic settings" to gather all insights of sign-in events to the workspace of Microsoft Sentinel. The following assets can be deployed as part of the content hub solution "Azure Active Directory":

AAD Solution

_Content hub solution for Azure AD can be used to deploy the related built-in analytics rule, workbooks and playbooks._

Security Alerts from "Azure AD Identity Protection": All risk detection will be stored in the "SecurityAlert" table under ProviderName "IPC" (= Identity Protection) by using this connector.

On-Premises Identity (Active Directory) in "Microsoft Sentinel"

Alerts from Microsoft Defender for Identity (MDI): Connector is listed as "Microsoft Defender for Identity (Preview)" and forward the alerts to the "SecurityAlert" table ("ProviderName" is named like the previously product name). I can strongly recommend to use the "Microsoft 365 Defender" connector which offers bi-directional sync and also the option to ingest raw or detailed logs from MDI to Microsoft Sentinel.

./media/identity-monitoring/AzIdentity_AzSentinelM365Connector.png

"Microsoft 365 Defender" connector allows to stream the already known "Advanced hunting" tables (with raw event data) from the "M365 Security Portal" to Microsoft Sentinel. This is available for all M365D services excluding Vulnerability Management.

Collected (security) logs from domain controllers (via Log Analytics Agent or Azure Monitor Agent) can be used to gain insights of the on-premises environment. Workbooks to analyze security events to detect usage of insecure protocols (NTLMv1, WDigest) or visualize anomalies and user activities across "Identity & Access" operations are available.

./media/identity-monitoring/AzIdentity_AzSentinelWorkbookIAM.png Workbook template "Identity & Access" uses logs from the "SecurityEvents" table to visualize authentication events and user activities in your "Active Directory" environment.

Cloud Sessions (Microsoft Defender for Cloud Apps) in "Microsoft Sentinel"

Data from Defender for Cloud Apps: All alerts from MDA will be stored in the table "SecurityAlert". The second data type of the connector collects the "Discovery Log" ("Shadow IT" reports) from MDA to the "McasShadowItReporting" table in the Sentinel workspace. It's strongly recommended to use the "Microsoft 365 Defender Connector" which offers you (in addition) bi-directional sync and options to ingest advanced hunting table of CloudAppEvents to MicrosoftSentinel.

Collaboration Platforms (Office 365 Services) in "Microsoft Sentinel"

Data from Office 365 Logs: Activity logs from SharePoint, Exchange and Teams will be stored in the "OfficeActivity" table by this connector.

Alerts from "Microsoft Defender for Office 365" (MDO): Data connector is named as new product name "Microsoft Defender for Office 365 (Preview)" (MDO) and allows to store many types of alerts from the "Office Security and Compliance Center" to the "SecurityAlert" table. Advanced logs (data) and all types of alerts from MDO can be ingested by using "M365 Defender Connector" which includes also tables such as EmailEvents and UrlClickEvents.

Device / Endpoint Security (Microsoft Defender for Endpoint) in "Microsoft Sentinel"

Alerts from "Microsoft Defender for Endpoint" (MDE): Data connector to fetch alerts generated by endpoint protection is available under the new product name "Microsoft Defender for Endpoint" (MDE). Alerts will be also stored (similar to the other M365 Defender products) in the "SecurityAlert" table.

  • Many playbooks are available from Microsoft to use MDE to restrict entities (block IP address, URL, app execution,...) or further interaction (get investigation package or list of the Threat & Vulnerability Management) as part of an automated response process.

Data from M365 Defender (Device*): Advanced logs from the already known "advanced hunting" tables (DeviceInfo, DeviceLogonEvents,...) in "M365 Defender" will be streamed to "Microsoft Sentinel" by the unified connector.

  • This allows new hunting and correlation options between logs that can be only collected from Azure Monitor/Microsoft Sentinel and M365 integrated logs.
    • Example: "Windows Sign-in events" ("SigninLogs" table, sourced from Azure AD) can be correlated natively with entries of the "DeviceLogonEvents" table which covers local sign-in and authentication events from MDE.
  • M365 Defender and Microsoft Sentinel are using KQL as query language. Therefore all your existing hunting queries from MDE/M365 Defender should be easily used in Microsoft Sentinel as well.

Investigation of Incidents in "Microsoft Sentinel"

Incidents and Workbooks in "Microsoft Sentinel" blade

Incidents blade of "Microsoft Sentinel" shows all alerts from the "connected data sources" in Microsoft Sentinel. This includes MDA "custom alerts" (e.g. activity policy "Elevated Global Admin to Azure Management") and all other built-in policies or detections (e.g. "Mass Download by a single user" in MDA). But also alerts from "Microsoft Defender for Cloud" ("Access from a Tor exit") and "Analytic rules" (from Microsoft Sentinel) on Azure Activity Logs ("Rare subscription-level operations") will be listed.

./media/identity-monitoring/AzIdentity_AzSentinelIncidents.png

It's important to understand the difference between incident and alerts in Microsoft Sentinel: Incidents are a group of related alerts and will be correlated by Microsoft Sentinel.

  • As already described, alerts from connected security products (MDE, MDI, MDC, etc.) are only displayed as "Incident" if "Microsoft Security Incident Creation Analytic Rules" are configured in the "Analytics" blade.
  • Built-in (templates) or custom analytic rules can be grouped as "Incident" if an alert is triggered (enabled by default).

It is also important to know the different types of analytic rules and the logic behind them.

Templates of various workbooks are included that gives you an advanced view of incidents:

  • Incident Overview (In-depth information to a specific incident case)
  • Investigation Insights (timeline and trend of incidents combined with detailed information about entities)
  • MITRE ATT&CK (Visualizing coverage of "MITRE ATT&CK" framework on Microsoft Sentinel)

Investigation Graph

Investigation between security events based on "device" or "user" detections but also from "cloud" or "on-premises" resources can be hard. Sentinel offers a visualization of raw data and timeline to increase the visibility of context and helps to start your investigation on relation between entities of the incidents. Therefore, Investigation graph can be very useful for investigate your incidents.

Recently, Microsoft introduced the "Entity Insights" feature which shows detailed information of the related entities in the "investigation graph".

./media/identity-monitoring/AzIdentity_AzSentinelInvestigationGraph.png

Investigation starts on "Mass Download" incident and exploring all other related alerts from the entities. At the end, a comprehensive attack timeline and visualized progression of events will be shown. Detections of "Brute-Force" against "Active Directory" and the "Azure Portal" can be analyzed in the one investigation step.

Advanced multistage attack detection

Advanced multistage attack detection is based on machine learning ("Fusion" technology) and automates the correlation on various types of attack scenarios. This includes data exfiltration, lateral movement and malicious administrative activities.

./media/identity-monitoring/AzIdentity_AzSentinelFusion.png Fusion detects a multistage attack and build an incident with collections of related alerts.

Entity Behavior

User Entity Behavior Analytics (UEBA) allows investigation of entities (such as user or devices) and their behavior based on Microsoft Sentinel data.

  • Onboarded data sources and their raw data will be analyzed by the "UEBA Engine" in Microsoft Sentinel to find anomalies.
  • User information will be synchronized from "Azure AD" to enrich user profiles in the UEBA entity pages.
  • Details on the architecture and engine to identify advanced threats with this feature are documented by Microsoft.

UEBA can be enabled from the "Entity behavior" blade in Microsoft Sentinel. Selection of data sources (used by UEBA) can also be configured in this blade and includes "Azure AD" (Audit / Sign-in logs), "Active Directory", "Azure Activity" and "Security Events" (from all connected Microsoft Security products). Scoring and timeline of the "Entity pages" are longer visible in comparison with the MDA "user page".

Microsoft has been released also a solution which allows to use UEBA data as part of hunting query.

Enriched events from the "UEBA engine" will be stored in the "BehaviorAnalytics" table and are readable as (table) entries by using KQL queries. Microsoft is also using this table to visualize "UEBA results" in the workbook template "User And Entity Behavior Analytics". The founded anomalies will be scored with "Investigation Priority Score" and mapped to the "MITRE ATT&CK" framework.

Analytics from "UEBA" based on accounts, IP addresses and hosts entities can be displayed in the "Entity behavior" blade.

./media/identity-monitoring/AzIdentity_AzSentinelUEBA.png Entity pages shows an "Alerts and Activities Timeline" with all incidents by "Microsoft Security products" (generated by incident creation rule) or analytic rules (built-in or custom queries) and anomalous detections based on the behavioral learning in" UEBA". Insight box visualize anomalous activities and sign-in events from the various data sources.

Hunting Queries

Over hundreds of hunting queries are already integrated and can be used by "Security Analysts" to start hunting on various types of threats incl. "initial access" or "privilege escalation". The list of hunting queries can be filtered by "data sources" and "tactics". All queries are written in KQL and can be edited or customized. New hunting queries can be created from the blade and Microsoft is adding new "out of the box" queries on a regular basis.

Integration and Response in "Microsoft Sentinel"

Playbooks

A logic app can be triggered to automate "threat response" when an "analytic rule" generates the alert. All logic apps that includes "Microsoft Sentinel alert trigger" can be used as "Playbook". Microsoft describes the configuration of this playbooks in one of the Microsoft Sentinel tutorials. As already mentioned, many logic app templates are available from GitHub. Monitoring of playbooks is an important part of daily operations (especially if it's an essential part of your incident and response process). Workbook for "Playbook Health" might be helpful to get an overview about failed runs and latency.

In addition, there is also a "Logic App connector" for Microsoft Sentinel which allows to update or use information from incidents.

WatchList

Microsoft has introduced Watchlist as feature to collect data from "external sources" for correlation in the analytic rules. Items of the WatchList can be updated by a Logic App. Various WatchList templates are available to identify sensitive resources like service accounts or VIP users and building identity correlation (between multiple accounts).

Notebooks

Microsoft Sentinel allows to use "Jupyter notebooks" running on "Azure Machine Learning" (AML) platform and using "Microsoft Sentinel" data. Notebook templates are already included such as an "Entity Explorer for Account" or "guided hunting on anomalous Exchange Online Sessions".

Notebook are very powerful for hunting of security threats and allows enhancement of existing "Microsoft Sentinel data" by external threat intelligence.

Considerations and References of "Microsoft Sentinel"