Ingesting Azure Sentinel Incident information into Log Analytics Part II

Introduction

This is a continuation of the post Ingesting Azure Sentinel Incident information into Log Analytics. There are a few things that I want to clarify/rectify in it.

I was working on the output from my last post to make a useful workbook from it and noticed a few things.

Misspelling

I misspelled “severity” when creating the JSON string that I use to create the new log. I noted this in last post.

Wrong URL

I also used the wrong URL to get the information. While using the “cases” URL will work, it appears to be outdated. The portal uses the “incidents” URL so I will as well (more on that later). I also noticed that are some significant changes to what the properties are called.

Changed my mind

Because of issue #1 and due to the fact that these calls are still in preview and subject to change (with hopefully new and even more useful fields), I decided to change my view on whether to use the “Use data as is” step rather than the “Creating your own column names” step. This way if new information is added to the REST call, it will automatically be added to my call.

While working on the workbook I was changing all the names of the fields in any case so, since I had to do it anyways, it really defeats the main argument that I had for not using the “Use data as is” steps.

Publish Logic App

As soon as I figure out how to publish the logic app to GitHub without having all the links to my Azure Sentinel instance I will, as well as the workbook I am working on (which will be a future post). If anyone knows of a good link that tells me how to do that please post it in the comments. Thanks.

2 thoughts on “Ingesting Azure Sentinel Incident information into Log Analytics Part II

Leave a Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.