I was working with a team that was wanting to do this as well and we explored several options and came up with the best short term option until something is officially supported in the TA. I wanted to provide that information for others that happen across this post.
Our Solution
• Microsoft publishes documentation on exactly how to do this with their log integrator solution. (https://docs.microsoft.com/en-us/azure/security-center/security-center-integrating-alerts-with-log-i...) This is where we landed after considering and throwing out other options. It’s well documented by Microsoft and seems fairly trivial to implement
• Optionally, once the data is ingested into Splunk, the recommendation is to CIMify the data using the Alerts DM (http://docs.splunk.com/Documentation/CIM/latest/User/Alerts)
• From there you can create a new Correlation Rule that regularly scans the Alerts DM for new alerts and creates notables
Other Explored Options
• Using the Splunk Microsoft Cloud TA to read the data from the Blob storage. During our testing we found that Alerts are stored in encrypted format in the blob storage and so using the Cloud TA in existing form is not an option because of this encryption
• Using the Azure Security Center REST API (https://msdn.microsoft.com/en-us/library/mt704049.aspx) This is a viable option but has several drawbacks. The REST API input is limited. You must retrieve all active alerts on each call. There is no way to say, give me the new alerts since the last call, so deduplication needs to be managed by your calling script or in Splunk. Moreover, to mitigate potential performance impact of this limitation, you’d almost certainly have to implement bi-directional communication between ES and ASC when the notable is worked to close the alert. That was outside of the scope of what we needed to do. To be clear, I’m not saying that performance issues exist or are imminent in this design, simply that I suspect they could occur and it was enough to steer us toward the log integrator solution
Caveats
• As I stated previously, we didn’t/don’t have the need for bidirectional communication back to ASC. That’s a layer of complexity that wasn’t considered in our analysis, but it seems reasonable that an adaptive response action to call the ASC REST API would work for this
• We've actually not yet done the integration, so while we expect smooth sailing, we could run into bumps in the road that slow us down
