You wouldn’t want to jump over from Azure Security Center and Azure Sentinel to manage and operate security. We all know what they are and how they are used for which purpose. The ultimate goal would be to reduce effort of jumping, as well as to create a single pan of glass for your security governance and operation.
In this article, let’s explore on how to achieve the single-pan-of-glass goal, as well as notes that Microsoft may have never told you publicly.
Azure Security Center Connector
There may be a confusion about data collection in ASC setting versus alert that you can export to a Log Analytics workspace. In the past I wrote an article to explain a difference between these areas.
Again, the workspace you configure in ASC setting may store ASC alert, but not all of the alerts. And the only way to make sure ASC alerts are fully collected is using Continuous Export.
What about ASC Connector that Azure Sentinel supports? If you go to Connector page in Azure Sentinel you will see Azure Security Center in the list.
There are prerequisites Microsoft clearly indicated in the page, or here to get ASC alert.
You don’t need to be a global administrator to connect ASC. But if you are a global administrator then you are the king. Security Admin is enough, plus Log Analytics Contributor.
To programatically check Azure Security Center and connect to Sentinel, read this article
Once ASC from a subscription is connected its alerts will be streamed to the Log Analytics workspace Azure Sentinel is associated with. That sounds like Continuous Export doesn’t it? In fact it does. However the streaming frequency and ingestion latency would not be the same – only Microsoft knows that.
Manage ASC Alert from Azure Sentinel Incident
An incident is created every time an alert is triggered based on analytics rule threshold. Specific to ASC, our goal is to create an incident every time ASC has an alert. Your idea would be to write an analytics rule like the following one
SecurityAlert | where TimeGenerated >=ago(1d) | where ProductName == "Azure Security Center"
and give it an appropriate schedule. Does this sound like a good approach? In fact it is not. Note that the way Azure Sentinel works is to use your analytics query rule against the workspace it is associated with in a pre-defined schedule setting (e.g. Rule period, rule frequency). So imagine at the time it runs the query it sees 4 records in the result. As long as the result matches rule threshold (saying result is greater than 0), it creates an incident. So that incident for your scheduled analytics rule for ASC looks like as follows:
Look at the screenshot above. There are 6 events (6 ASC alerts in a result) within a single incident. That doesn’t meet your expectation definitely. Tuning the schedule setting to get thing like “Create 1 incident for 1 ASC alert” seems to be impossible (or the chance to get it is extremely rare)
The answer in this case is to use the built-in ASC analytics rule that Microsoft provides.
There are two ways ensure every time ASC creates an alert, Azure Sentinel creates an incident associated to that alert. The incident name is exactly the same with ASC alert name. This built-in rule definitely integrates with Microsoft back-end to do the job. It would’t run any Kusto query like what we may think. So ensure to use it if you want to achieve the goal.
Another note is if you haven’t configured workspace for data collection you should be still fine. But if you don’t connect ASC from Azure Sentinel ASC Connector page, your ASC won’t send alert to create an incident in Azure Sentinel.
The other way is to go to ASC Connector page and you can see the Enable option at the bottom. If you already have the built-in ASC rule the enable button is grayed. Unless it validates and allows you to enable. Once you click Enable, it automatically creates the built-in ASC rule for you.
If you want to create ASC alert, refer to this article (http://azsec.azurewebsites.net/2019/12/02/simulate-alerts-to-be-caught-by-asc/)