This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
One of the biggest advantages of the cloud in general and Azure Sentinel, in particular, is being API focused. SIEM products are integration savvy, whether with telemetry sources or with other management platforms. The cloud makes automating this integration critical to tackling the ephemeral nature of resources. In this evolving blog post, we will cover Azure Sentinel integration and automation capabilities.
Data integration
Azure Sentinel uses Azure Log Analytics for log management and the Log Analytics APIs serve Azure Sentinel.
The Query API
Azure Sentinel enables easy and fast API access to the workspace, Azure Sentinel's primary data store. This enables you to use Azure Sentinel as your data lake and build your own algorithms and applications over the data. To do that, send your KQL queries using the Log Analytics query API. Alternatively, use PowerShell or the Logic Apps Log Analytics connector to query using the API.
Also, to collect event data, the Azure Sentinel workspace stores alerts in the SecurityAlert table and bookmarks in the HuntingBookmark table, which can be accessed using the query API. Incidents are not stored in the workspace but can be read using the management API discussed below.
The Data Collector API
You can ingest data to Azure Sentinel using the Log Analytics Data Collector API. You can directly use the API using your preferred programming language, but also use tools such as the Log Analytics agent, Logstash and Logic Apps without programming. The API and the different ways to use it are discussed in the custom connectors blog post.
The Graph Security API
The Graph Security API offers a direct interface, which may be easier to use for special popular data access use cases:
- Read Azure Sentinel's alerts.
- Ingest TI to Azure Sentinel utilizing the built-in TI based analytics without modifications. Note that this cannot be achieved with the data collector API as it writes to custom tables rather than to the standard TI table, ThreatIntelligenceIndicator. See this blog post as an example.
Management integration and automation
Using automation for deployment and management is always a cost saver. For the cloud, in which resources are often ephemeral, automation is ever more important, and the same applies to service providers which need to on and off-board customers as efficiently as possible. Management APIs are also important to tie processes, and not just data, into other systems in the organization such as a service provider's portal, a workflow system or a ticketing system.
The Azure Sentinel API is still in preview and can be found here. We do expect small changes before it becomes generally available (GA). We will update this blog post on changes and when it becomes GA. Looking to include the API calls in an ARM template? the newly introduced scripting capability within ARM templates enables including any Sentinel API call in an ARM template. For more details refer to “Extending Azure Resource Manager (ARM), Azure's control plane” from Ignite 2019
As mentioned before, the API allows access to incident data, not available through the query API. You can find the export all incidents script a useful example for doing that.
Using the management API to automate content deployment
The most common use for the API is to automate the deployment and update of Analytics Alert Rules and hunting queries.
Two open-source implementations of the API you might find useful for this purpose are:
- Automating analytics and hunting rules deployment using AzSentinel (this is a useful wrapper around the API below)
- Example of scripts and DevOps pipelines integration (using AzSentinel when relevant)
Automated deployment for other resources
Azure Sentinel uses other resources which are part of the Azure environment and for which you would need to use their own deployment automation mechanism:
- Workbooks: use ARM. To ensure the workbook is listed in Sentinel:
- Set the sourceId to the workspace ID (should look similar to this /subscriptions/… /resourcegroups/…/providers/microsoft.operationalinsights/workspaces/…)
- Set the category to “sentinel”
- Logic App playbooks: use ARM. To ensure the playbook appears in Sentinel:
- It has to use the Sentinel trigger
- Be in the same subscription as the workspace.