Rediger

Del via


Auditing and health monitoring in Microsoft Sentinel

Microsoft Sentinel is a critical service for advancing and protecting the security of your organization’s technological and information assets, so you want to be sure that it's always running smoothly and free of interference.

You want to verify that the service's many moving parts are always functioning as intended, and it isn't being manipulated by unauthorized actions, whether by internal users or otherwise. You might also like to configure notifications of health drifts or unauthorized actions to be sent to relevant stakeholders who can respond or approve a response. For example, you can set conditions to trigger the sending of emails or Microsoft Teams messages to operations teams, managers, or officers, launch new tickets in your ticketing system, and so on.

This article describes how Microsoft Sentinel’s health monitoring and auditing features let you monitor the activity of some of the service’s key resources and inspect logs of user actions within the service.

Health and audit data storage

Health and audit data are collected in two tables in your Log Analytics workspace: SentinelHealth and SentinelAudit

Audit data is collected in the SentinelAudit table.

Health data is collected in the SentinelHealth table, which captures events that record each time an automation rule is run and the end results of those runs. The SentinelHealth table includes:

  • Whether actions launched in the rule succeed or fail, and the playbooks called by the rule.
  • Events that record the on-demand (manual or API-based) triggering of playbooks, including the identities that triggered them, and the end results of those runs

The SentinelHealth table doesn't include a record of the execution of a playbook's contents, only whether the playbook was launched successfully. A log of the actions taken within a playbook, which are Logic Apps workflows, are listed in the AzureDiagnostics table. The AzureDiagnostics provides you with a complete picture of your automation health when used in tandem with the SentinelHealth data.

The most common way you use this data is by querying these tables. For best results, build your queries on the pre-built functions on these tables, _SentinelHealth() and _SentinelAudit(), instead of querying the tables directly. These functions ensure the maintenance of your queries' backward compatibility in the event of changes being made to the schema of the tables themselves.

The SentinelHealth table isn't billable and incurs no charges for ingesting health data. The SentinelAudit table is billable, and as in other areas of Microsoft Sentinel, costs incurred depend on the log volume, which might be affected by the number of activities and changes made on related rules. For more information, see Plan costs and understand Microsoft Sentinel pricing and billing.

Important

The SentinelHealth and SentinelAudit data tables are currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure Previews for additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

Questions to verify service health and audit data

Use the following questions to guide your monitoring of Microsoft Sentinel's health and audit data:

Is the data connector running correctly?

Is the data connector receiving data? For example, if you've instructed Microsoft Sentinel to run a query every 5 minutes, you want to check whether that query is being performed, how it's performing, and whether there are any risks or vulnerabilities related to the query.

Did an automation rule run as expected?

Did your automation rule run when it was supposed to—that is, when its conditions were met? Did all the actions in the automation rule run successfully?

Did an analytics rule run as expected?

Did your analytics rule run when it was supposed to, and did it generate results? If you're expecting to see particular incidents in your queue but you don't, you want to know whether the rule ran but didn't find anything (or enough things), or didn't run at all.

Were unauthorized changes made to an analytics rule?

Was something changed in the rule? You didn't get the results you expected from your analytics rule, and it didn't have any health issues. You want to see if any unplanned changes were made to the rule, and if so, what changes were made, by whom, from where, and when.

Health and audit monitoring flow

To start collecting health and audit data, you need to enable health and audit monitoring in the Microsoft Sentinel settings. Then you can dive into the health and audit data that Microsoft Sentinel collects:

Activity More information
Run queries on the SentinelHealth and SentinelAudit data tables from the Microsoft Sentinel Logs page.
  • Data connectors
  • Automation rules and playbooks (join query with Azure Logic Apps diagnostics)
  • Analytics rules
  • Use the auditing and health monitoring workbooks provided in Microsoft Sentinel.
  • Data connectors
  • Automation rules and playbooks
  • Analytics rules
  • Use Microsoft Sentinel's execution management tools to monitor and optimize scheduled analytics rules' execution
  • Monitor and optimize the execution of your scheduled analytics rules
  • Export the data into various destinations, like your Log Analytics workspace, archiving to a storage account, and more.
  • Diagnostic settings in Azure Monitor