Identity Security Monitoring in Microsoft Cloud Services
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”
- Azure Monitor:
Operational Logs and Alerts of “Azure AD” and “Azure Workloads”
- Microsoft Cloud App Security:
Unified SecOps of connected “Cloud Apps” and “Hybrid Identity”
- Microsoft 365 Defender:
Unified SecOps of M365 Services
- Azure Sentinel: “Single pane of glass” across Azure, M365 and “3rd party solutions”
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.
“Microsoft Defender for Identity” (MDI), “Microsoft Cloud App Security” (MCAS) and “Azure AD Identity Protection” 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.
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.
At 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.
This blog post 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 writting this blog post. Therefore the content and statement can be outdated since the article was published in December 2020.
Note: Microsoft announced many product name changes at the Ignite 2020. 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.
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.
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:
- Azure Activity Logs: Platform logs of Azure which includes details on various events in your subscriptions and resources (including administrative activities, service health, recommendations). Changes of Azure RBAC are also part of this activity logs.
- Azure Resource Logs (Diagnostic Logs): Insights and “Audit Logs” of operations that were performed within an “Azure resource” are stored here. This includes the logging of identity and access (IAM)-related services such as “Azure KeyVault”. You need to configure the diagnostic settings to monitor access of secrets and certificates which are stored in the vault.
- Storage of Security Events in Log Analytics:
Collect all (security) events from servers in Azure and non-Azure/On-Premises infrastructure as part of the Azure Security Center and Data Collection.
- Collect data from physical/virtual server (hybrid environments) with Azure Monitor and Log Analytics Agent (Event Logs and Performance Counter)
- Data Collection of “security logs” to Log Analytics can be configured in “Azure Security Center” by choosing “All Events”, “Minimal” or “Common” options. Therefore it’s strongly recommended to use the same workspace for “Azure Security Center” and “Azure Monitor” logs.
- Use cases for (Active Directory) Domain Controller log queries:
Azure Security Center (ASC) and “Azure Monitor”
Continous Export allows to forward alerts and recommendations to “Azure Event Hub” or “Log Analytics”. This solution is divided in two different scopes: 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.
- Recommendations: Checks on-boarded subscriptions and their resources of recommendations around Identity and access „resource security“.
Various types of IaaS and PaaS resources (VMs, App Service, Storage,…) will be protected against threats including identity-related attacks (e.g. „A logon from a malicious IP has been detected“) or malware (e.g. Mimikatz or any “attack tools”). Triggering of alerts can be tested as described in the „Alert validation“ guide of Microsoft.
- Azure Defender for Servers and Integration of Microsoft Defender for Endpoint: Alerts for Windows and Linux covers attack sources such as “anonymous or malicious IP addresses” and integrates “Microsoft Defender for Endpoint” for extended scenarios. You‘ll get advanced post-breach detections and alerts from “Endpoint Protection”, alongside of automation of onboarding sensors.
- Azure Defender for PaaS and threat protection capabilities: Various Azure PaaS services such as Azure App Service, containers, SQL or KeyVault can be also protected by “Azure Defender”. Other platform services as the management layer of Azure (Resource Manager) or network layer are also included. Detection of unusual or risky operations in the Azure subscription are powered by MCAS.
- Data schema describes fields and data types of the ASC security alerts.
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
- Azure AD Sign-In Logs: Overview of authentication and authorization events of all users. Details on the content are defined in the sign-in logs schema
- Azure AD Audit Logs: Activities of tasks that is performed by a user or admin of your Azure AD tenant. Audit Log schema defines the content of this activity log.
- Azure AD Non-Interactive Logs: Microsoft updated the logging capabilities in Azure AD as addition to the above mentioned classic “Azure AD Reports”.
- Azure AD Provisioning Logs: This log gives you detailed insights of provisioning users, roles and groups from or to Azure AD. Log schema for Azure Monitor is also documented in MSDocs.
Non-supported reports in Azure Monitor
- 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).
- Various “risk detections” are available 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.
Risk detections from “Cloud App Security” (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.
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 “Azure 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 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:
Integration and Response in “Azure Monitor”
- Alerts and Logic Apps: Azure Monitor is able to trigger complex actions based on defined rules (such as signal logic based on KQL custom log search). This gives you many options to integrate your workflows as part of “Azure Logic Apps” or any other 3rd Party systems.
Considerations and References of Azure AD Logging by “Azure Monitor”
- Microsoft’s “deployment guide of Azure AD Monitoring” 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).
- 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.
- Example: Azure EA portal and changes of ownership will not be audited but has effects on Azure RBAC!
- Rate limitation of „Azure Alerts“ should be considered for your service emergency and operational notifications.
- Identity Protection provides new 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 Azure 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!
MCAS and “Defender for Identity”: Unified SecOps of connected “Cloud Apps” and “Hybrid Identity”
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 MCAS
IaaS/PaaS (Cloud and on-Premises) in MCAS
MCAS allows you to connect Microsoft‘s Azure platform and other cloud platform provider (AWS and Google Cloud Platform) via “App Connector”. This makes the „Activity logs“ available in MCAS 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.
Azure Security Center (ASC) and MCAS-Integration
Security Configuration Assessment results of MCAS will be collected from the “Azure Security Center”. 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).
Cloud Identity in MCAS
Azure AD audit and sign-in events are covered by the „Office 365 connector“ in MCAS. 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 (yet).
- Severity of (cloud) identity risk alerts can be managed by MCAS 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.
- Some identity risk detections will be detected by MCAS (such as “impossible travel” or “inbox manipulation rule”) and results will be forwarded to Azure AD Identity Protection (and displayed in the portal blade as well). Follow the Identity protection playbook to simulate the attack scenarios and trigger the detection/response.
All “Identity Protection” risk detections will be listed in the MCAS alerts view.
On-Premises Identity (Active Directory) in MCAS
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.
- Integration of MDI with Defender for Endpoint allows you to laverage the detection from events of the domain controller to all endpoints. Furthermore it allows you to see open MDI alerts as badge in the MDE portal.
Integration of MDI with MCAS is mandatory for environments where both solutions are in use. More and more features around MDI seems to be moved to the MCAS portal (such as the new “hunting experiences”). All activities and detections of MDI will be also included in the UEBA if integration is configured.
Attacks on Active Directory (On-Premises) will be detected by MDI and generates an alert in the MDI portal.
New “hunting experience” allows to use MCAS portal for unified incident management between “Active Directory” and “Azure AD” alerts.
- MCAS 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 “MCAS connected apps”.
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 are adding new detection methods that raised up. A good example is the vulnerability detection of ZeroLogon which was introduced 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 Cloud App Security
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:
- “Cloud Discovery” allows you to detect usage of cloud apps from proxy/firewall logs or machine-based discovery (from MDE). Integrated “Cloud App Catalog” shows a “risk score” and detailed information (security factors, industry- and legal regulations) to discovered apps. Classification as “unsanctioned” will start blocking the usage of the app.
- Microsoft Defender for Endpoint (MDE) in MCAS has many benefits around “Cloud Discovery” (ingestion of discovered machine data) and the usage of custom network indicators (to block unsanctioned cloud apps).
- Discovery logs can be enriched with “Azure AD” username data. This replaces the original username from the proxy or firewall traffic logs by the Azure AD user name.
- MCAS provides “App Connectors” for some cloud provider to get advanced visibility and protection of sanctioned/connected apps. Insights of user/access management, activity logs and file/sharing control will be collected via “API connections” to the supported cloud products (GitHub Enterprise, ServiceNow, etc.).
- Sessions to Azure AD-integrated apps can be managed (for limited access) in MCAS with “Conditional Access App Control”. MCAS acts as a reverse proxy to control sessions of the configured cloud app. This gives you various compliance options such as preventing data exfiltration or real-time monitoring of user activity (anomalies) in the session.
MCAS 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 MCAS
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 MCAS 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 MCAS:
- 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 MCAS “app connector”.
- Alerts of “Microsoft Defender for Office 365” (MDO) are also visible in the “MCAS Activity Log” and allows you to create custom policies in MCAS. Sami Lamppu has also given some details about this in one of his blog posts.
Device / Endpoint Security (Microsoft Defender for Endpoint) Integration in MCAS
“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 MCAS. But also insights from MCAS will be displayed in the (new) Endpoint Security Portal.
Signal forwarding from “Microsoft Defender for Endpoint” (MDE) to MCAS 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 “MCAS 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 MCAS. 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 MCAS
User and Entity Behavior Analytics (UEBA) in MCAS
- (Hybrid) Identity Threat Investigation: The “user page” in MCAS 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 MCAS (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 MCAS 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 “MCAS 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).
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 MCAS
- Identity Security Posture: Assessment of various security critical “Active Directory” configurations that includes also instructions to remediate or resolve the findings.
- Manage OAuth apps:
Risky apps can be investigated by the discovered “OAuth apps” in MCAS. Furthermore, you should also be able to configure an app policy to monitor “OAuth apps” on various criteria (incl. permission level) and revoke the app (if needed).
- Built-in “OAuth” app anomaly detection policies are already configured to detect malicious consent grants, misleading publisher/product names or activity to suspicious apps.
Integration and Responds in MCAS
Control of your identities in connected apps/resources can be achieved by monitored activities and signals by MCAS. 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 MCAS 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.
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 MCAS that are ready for use. Many of them are essential and strongly recommended to be enabled and configured in your MCAS 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 “Cloud App Security”
- Interaction, integration and options of MCAS with other services in “Microsoft 365” are numerous and plays a significant role. Check out MCAS design diagram (by ManagedSentinel.com) to get an overview of those connections.
- Regular check of “MCAS Changelog” should be made to be informed about changes in your tenant and new features or risk detection.
- MCAS 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.
- Service health can be monitored on the “MCAS status page” and should be integrated for notification of service issues or delays of detections
- Daily operational tasks for MCAS are documented by Microsoft.
- Consider Microsoft’s best practices of implementing MCAS 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.
- MCAS 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!
- MCAS 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 MCAS. Sami Lamppu has written a detailed blog post about it!
- RBAC in MCAS 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 MCAS features are available as “Ninja Training”
Considerations and References of Microsoft Defender for Identity (MDI)
- 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 the blog post (by Derk van der Woude).
- 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’s no option to collect Sensor health status!
- 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](https://docs.microsoft.com/en-us/defender-for-identity/role-groups#types-of-product-short-security-groups). 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 (incl. 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
- 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”.
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”.
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 Azure Defender are not visible for hunting in this portal.
Cloud Identity (Azure Active Directory) in “M365 Defender”
Incidents / AlertInfo: Risk detections from “Azure AD Identity Protection” seems to be not included in the “Incidents” and aren’t visible in the table “AlertInfo”. MCAS feeds many type of alerts to “M365 Defender” and “sign-in risk events” (detected by MCAS) is one of them. MCAS will be named as “ServiceSource” and “DetectionSource” in the log entries. Nevertheless, alerts from the “Risky sign-in” policy in MCAS, which collects also all “Identity Protection” risks (detected by “AAD Identity Protection”), can not be founded in “M365 Defender”.
- “Password Spray” will be detected by “Identity Protection” and listed in MCAS as “Risky sign-in” (as you have seen in the screenshots of previous article section). But it is not visible in the “AlertInfo” table or as part of an Incident in “M365 Defender”.
“Impossible Travel” is detected by MCAS and will be shown in the “Identity Protection” blade of Azure AD. But this risk detection is also listed as MCAS alert (“Impossible travel activity”) and will be shown in the “Incident” view of “M365 Defender” and exists in the “AlertInfo” table.
Alerts from MCAS (and MDI) will be summarized as “Incidents” in the “M365 Security Portal”. Detections by “Azure AD Identity Protection” (e.g. Password Spray) are missing. Alerts from connected apps in MCAS are also not listed in this case (e.g. “Mass Download” from OneDrive or SharePoint) or custom activity alerts (e.g. Elevated GA to Azure Management in Azure Portal).
In comparison with the list of alerts in MCAS, not existing alerts in “M365 Defender” are bordered in red.
IdentityLogonEvents: Authentication events captured by MCAS 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 MCAS blade (filtered by “Successful or failed login-ins”). As already described, “non-interactive” logons or sign-ins by “service principal”/”managed identity” are not covered.
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.
UPDATE (Dec 18th): Azure AD audit logs are now integrated in M365 Defender for advanced hunting. Events will be streamed from the “Office 365 connector” and log data is available in the CloudAppEvents table.
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 MCAS and MDI is enabled. MCAS 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 MCAS.
Recently, Microsoft added the opportunity to use “Advanced Hunting” based on events captured by MDI. Another benefit (compared to MDI queries in the MCAS 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 MCAS 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 MCAS and shows similar results to a filtered “Activity Log” (by “Active Directory” app in the MCAS 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 Cloud App Security) 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 MCAS (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:
- EmailEvents (e-mail delivery and blocking events)
- EmailAttachmentInfo (file attachment)
- EmailPostDeliveryEvents (security event after e-mail delivery)
- EmailUrlInfo (URLs / Safe Attachment in E-Mails)
CloudAppEvents: Activities from “Exchange Online” and “Microsoft Teams” (monitored by MCAS) are available for hunting here. Other O365 services are not supported yet! OneDrive and SharePoint Online will be introduced in early 2021 and the existing “AppFileEvents” will be replaced at this time.
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.
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 only remediation actions on suspicious or malicious “Devices” or “Emails”. 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”.
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 365 Defender Ninja Training is a great resource to learn more!
- Advanced Hunting Cheat Sheet gives some good samples and uses cases of queries across the supported services in “M365 Defender”
- Samples of Advanced Hunting Queries are available on GitHub and are ready to be used!
- Evaluate the “Attack Simulator” in the “M365 Security Center” to simulate attacks (such as phishing attacks) and start “security awareness” training for end-users
- Regular check on updates and changes in “What’s new in M365 Defender” or the message center in “Microsoft 365 admin center” is strongly recommended!
- Get an overview of the “M365 Defender” core features by Microsoft’s “educational training videos”
- Custom Detection Rules can be configured only with a frequency between 1-24 hours and built-in action as auto-response
- Default permissions in “M365 Defender” should be considered (to know who has access)
- Take a look on the “Interactive guide” to get an overview about the hunting and incident management capabilities
- Microsoft 365 Defender trial lab can be helpful to simulate attacks and learn the ways to resolve incidents or start advanced hunting.
- Public Preview of M365 Defender APIs allows integration and advanced hunting/queries programmatically
Azure Sentinel: “Single pane of glass” across Azure, Microsoft 365 and 3rd party (cloud) platforms
Sample use case: SecOps that needs a security 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. Azure 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.
Data Sources of “Azure Sentinel”
All of the following data sources can be connected to “Azure Sentinel” by data connectors. Alerts from the Microsoft Security products can be created as “Incident” automatically which is strongly recommended to have been implemented (for unified incident view). 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:
- KQL-based Dashboards (“Workbooks”)
- KQL-based Detections (“Analytic Rules”) and Hunting Queries
- Logic Apps for automated response or integration (“Playbooks”)
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.
IaaS/PaaS (Cloud and on-Premises) in “Azure Sentinel”
Azure 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. Azure Sentinel offers some “data connectors” to easily integrate the following data sources:
- Data from “Azure Activity Logs”: Selected subscriptions will stream their platform logs to the table “AzureActivity”.
- Insights of all operations and events within the “connected subscriptions” will be visualized by the built-in “Azure Activity” workbook. This gives you an overview about detected failures, warnings and caller activities to the “Azure Platform”.
- Eight different analytic rules are available for this “data source” including detection of anomalous privileged access such as “Suspicious Resource Deployment or granting of permission”
- Security-related “diagnostic logs” should be also forwarded to the workspace of Azure Sentinel. It allows you to use “Analytic rules” for detecting unfamiliar access activities e.g. in “Azure Key Vault” (mass secret retrieval or sensitive operations).
- Other Cloud Providers: Amazon Web Services (AWS) can be integrated to stream all “Management Events” to Azure Sentinel as well.
- Data from Syslog / Security Event Logs: This allows you to collect all security events from Windows and Linux machines by the “Log Analytics Agent”. Scope configuration of streamed events (All Events, Common and Minimal) can be configured as previously described in this blog post. This settings also defines the amount and scope of “raw logs” that will be stored in the tables “SecurityEvent” and “Syslog”.
- Azure Sentinel includes “analytic rules” to detect failed logon attempts or “Brute Force” attacks to your Linux servers. But also many detections for user management or (RDP) sign-in anomaly on Windows Servers are available. In total over 31 detection templates based on “(Windows) Security Events” and over 11 rules for “Syslog” can be enabled to use this “data source”.
- Azure Sentinel provides two ML-based behavior analytics to detect anomalous logins via SSH and RDP.
- Many workbooks are available to visualize the raw logs from servers in your environment including “Event Analyzer“(for audit object, file system or registry of Windows) or “Linux Machines” (for insights of Linux events and errors).
Azure Security Center (ASC) and “Azure Sentinel”
Alert Data from Azure Security Center (detected by Azure Defender): This connector allows to ingest alerts of detected threats by Azure Defender. The alerts will be found in the “SecurityAlert” table as ProviderName “Azure Security Center”.
- Azure Sentinel includes a unified workbook to get compliance, posture management and protection status (including trends) on your “Azure Security Center” data.
- Playbooks allows you to connect new “Azure Subscriptions” automatically on a scheduled basis or to automate the notification of incidents (to RBAC assigned Owners) or recommendation (incl. IAM configuration) of resources.
Cloud Identity (Azure Active Directory) in “Azure Sentinel”
Data from Azure AD Logs: Audit and Sign-ins will be collected but no sign-in logs of “Service Principals”, “Non-Interactive” or “Managed Identities” are covered yet. Therefore you have to configure the “diagnostic settings” in the “Azure AD blade” manually to gather all insights of sign-in events to the workspace of Azure Sentinel.
- Many KQL queries (analytic rules) are able to detect malicious activities such as “OAuth app” registrations. Analyses of sign-in attempts supports you to find initial access attacks such as brute force to Azure Portal or Azure AD PowerShell anomalies.
- Over 34 “out of the box” hunting queries related to Azure AD “Audit” or “Sign-in” logs are available and empowers “Security Analysts” to detect e.g. anomalous activities in “account creation”, “login to devices”, “role assignments” or “rare privileged account activity”. Hunting queries using multiple data sources alongside of Azure AD logs such as “Azure Activity Logs” or the “Behavior Analytics” from Azure Sentinel.
Three different workbooks for “Azure AD” are included as “templates” for visualization. Insights about Azure AD-related logs will be visualized or partly included in combined views in other workbooks.
This workbook shows unified events between activity logs from Azure but also audit and sign-ins logs from Azure AD.
- Auto-response on detected identity risks or threat detections can be extended by Playbooks. Microsoft offers samples for many actions such as prompt user for investigation details, isolate device of the user (by MDE) or revoke the sign-in session (token) by Microsoft Graph API.
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.
- Advanced correlation between incidents of unfamiliar and atypical detections are possible with analytic rules.
- Status management of risky users (confirm or dismiss) can be automated by Playbooks.
On-Premises Identity (Active Directory) in “Azure Sentinel”
Alerts from Microsoft Defender for Identity (MDI): Connector is listed as “Azure Advanced Threat Protection (Preview)” and forward the alerts to the “SecurityAlert” table (“ProviderName” is named like the previously product name).
Raw or detailed logs from MDI are not available in Azure Sentinel yet. Microsoft started to implement the “Microsoft 365 Defender” connector that seems to enable streaming of advanced logs in the future.
“Microsoft 365 Defender” connector allows to stream the already known “Advanced hunting” tables (with raw event data) from the “M365 Security Portal” to Azure Sentinel. Currently this is limited to “Defender for Endpoint” but seems to be coming for other M365 Defender products as well!
But at this time, KQL-based queries and hunting (on detailed logs) are useable in “M365 Defender” only.
Collected (security) logs from domain controllers (via Log Analytics Agent / Azure Security Center) 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.
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 Cloud App Security) in “Azure Sentinel”
Data from Cloud App Security: All alerts from MCAS will be stored in the table “SecurityAlert”. The second data type of the connector collects the “Discovery Log” (“Shadow IT” reports) from MCAS to the “McasShadowItReporting” table in the Sentinel workspace.
- Azure Sentinel integration will be also configured in the “MCAS portal” and allows to specify filters on the discovery logs.
- Data schema of the MCAS logs in Azure Sentinel are also documented by Microsoft.
- Discovery Logs in Azure Sentinel can be visualized by using the pre-configured “Workbook” template.
- Resolving MCAS alerts can be automated as part of Playbook (instead of PowerAutomate) in Azure Sentinel.
Collaboration Platforms (Office 365 Services) in “Azure Sentinel”
- User activities by these three workloads can be visualized in the “Office 365” workbook.
- Many analytic rules are available to detect suspicious “Office 365” activities but also some hunting queries on Exchange Online mailboxes, SharePoint downloads or Teams activities are available.
- Other compliance, operational or security logs from “Office 365” (such as Message Trace logs) are not included. Collecting the missing logs are described in a TechCommunity blog post and will be achieved trough Azure Logic Apps.
Alerts from “Microsoft Defender for Office 365” (MDO): Data connector is named as “Office 365 Advanced Threat Protection” (OATP) 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 are not available yet. As already mentioned, the “M365 Defender Connector” seems to improve the log integration between MDO and Sentinel in the future.
Device / Endpoint Security (Microsoft Defender for Endpoint) in “Azure Sentinel”
Alerts from “Microsoft Defender for Endpoint” (MDE): Data connector to fetch alerts generated by endpoint protection is also named by the old brand “Microsoft Defender Advanced Threat Protection” (MDATP). 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 “Azure Sentinel” by this new connector.
- This allows new hunting and correlation options between logs that can be only collected from Azure Monitor/Azure 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 Azure Sentinel are using KQL as query language. Therefore all your existing hunting queries from MDE/M365 Defender should be easily used in Azure Sentinel as well.
Investigation of Incidents in “Azure Sentinel”
Incidents and Workbooks in “Azure Sentinel” blade
Incidents blade of “Azure Sentinel” shows all alerts from the “connected data sources” in Azure Sentinel. This includes MCAS “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 MCAS). But also alerts from “Azure Security Center” (“Access from a Tor exit”) and “Analytic rules” (from Azure Sentinel) on Azure Activity Logs (“Rare subscription-level operations”) will be listed.
It’s important to understand the difference between incident and alerts in Azure Sentinel: Incidents are a group of related alerts and will be correlated by Azure Sentinel.
- As already described, alerts from connected security products (MDE, MDI, Azure Defender, 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 three 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 Azure Sentinel)
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”.
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.
Fusion detects a multistage attack and build an incident with collections of related alerts.
User Entity Behavior Analytics (UEBA) allows investigation of entities (such as user or devices) and their behavior based on Azure Sentinel data.
- Onboarded data sources and their raw data will be analyzed by the “UEBA Engine” in Azure 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 Azure Sentinel. Selection of data sources (used by UEBA) can also be configured in this blade and includes “Azure AD” (Audit / Sign-in logs), “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 MCAS “user page”.
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.
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.
Over 175 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 “Azure Sentinel”
A logic app can be triggered to automate “threat response” when an “analytic rule” generates the alert. All logic apps that includes “Azure Sentinel alert trigger” can be used as “Playbook”. Microsoft describes the configuration of this playbooks in one of the Azure 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 Azure Sentinel which allows to update or use information from incidents.
Recently, Microsoft introduces Watchlist as feature to collect data from “external sources” for correlation in the analytic rules. This enables also the possibilities of enrichment by external events or business data. One of Microsoft’s playbook samples is using “WatchList” to close an incident from known IP addresses. On this general approach as an example, you can use a playbook to ingest “Trusted IP addresses from Microsoft (backend)” to enrich false-positive events of unfamiliar locations.
Azure Sentinel allows to use “Jupyter notebooks” running on “Azure Machine Learning” (AML) platform and using “Azure 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 “Azure Sentinel data” by external threat intelligence.
Considerations and References of “Azure Sentinel”
- Azure Sentinel Ninja (Level 400) Training includes a great list of resources to start your study on Microsoft’s SIEM solution.
- Microsoft is offering many interesting webinars around Azure Sentinel! Check out the upcoming events or the records of the past webinars.
- One of my favourite session is “Tackling Identity” because of the high proportion of use cases and live-demos (KQL samples) that shows the advantages and technical possibilities of Azure Sentinel.
- Consider Microsoft’s Best Practices for Azure Sentinel
- Best Practices for designing Azure Sentinel and Azure Security Center workspaces is very important!
- Consider to create as few workspaces as possible!
- Azure Sentinel To-Go is a great way to build a lab environment with prerecorded data.
- Comparison between “Azure Sentinel” and “M365 Defender” is one of the most common question. Jan Geisbauer and Sami Lamppu has written very good blog posts to give an general answer to this question.
- Maarten Goet has written a great blog post why “VSCode” becomes essential for threat hunting with Azure Sentinel
- Enrichment with “Azure AD information” can be important to associate detailed information to “Azure Activity” or “Office 365” logs which is well described in this TechCommunity blog post.
- Enrichment of alert entities with other sources like MCAS or “Microsoft Defender for Endpoint” is also possible. A template and detailed video is available to build entity enrichment by a playbook.
- Deployment of Azure Sentinel can be automated as part of a centralized repository and CI/CD pipeline. This is a great approach if you have the need to manage staging or multi-tenant environments.
- Azure Lighthouse can be used for a multi-workspace view and tracking an attack multiple tenants. Collection of Azure AD or O365 logs from different tenants is also possible if you configure a custom data connector.
- Monitoring of the Workspace Health is one the daily operational tasks in Azure Sentinel. The workbook for usage reporting is essential to check latency, cost and table analysis (past, current and estimated size of tables) of your Log Analytics workspace / Sentinel instance.
- Microsoft offers a workbook to verify the monitoring health in Azure Sentinel. It’s strongly recommended to use this integrated workbook to check the health of agents and “data connectors” but also the connectivity and performance within Azure Sentinel.
- You want to learn KQL? Check the Basic KQL Course from Pluralsight or “Become a KQL Ninja” (KQL Internals Study Guide) by Huy.
Original cover image by 200degrees / Pixabay