Playbook (Logic App) - trigger - When Azure Sentinel incident creation rule was triggered

[erlendoyen]

Hi

i am attempting to use the trigger "When Azure Sentinel incident creation rule was triggered"  that's in preview.

but the playbook is not triggered even if i know that i have a new incident in Sentinel 

what's missing from the configuration? 

[#2]

@SocInABox If you are using the Incident trigger in a playbook, you can use the Automation rules feature of Azure Sentinel to have that playbook automatically run for any incident that gets created.

https://docs.microsoft.com/en-us/azure/sentinel/automate-incident-handling-with-automation-rules

[#3]

Thanks Gary, but I'm not sure you're saying a 'global' playbook is possible?
You're saying I still have to assign my playbook to each individual analytic rules automation but it will be auto triggered if an incident is fired for that rule.

Or are you saying there's a 'global' feature I don't understand?

[#4]

@SocInABox The Sentinel logic app triggers for incidents and alerts do not monitor Sentinel for new alerts (though that is understandable assumption). Rather those triggers configure the Logic App to be triggered or called by Sentinel. The logic app is waiting to be called.

Alert-based triggers are linked to specific scheduled analytic rules and can be run manually from an incident (scroll to the far right on the alerts list inside an incident). This option is limited to alerts generated by the scheduled rule-type.

Incident-based triggers are called by the new Automation rules. These can be setup to response to any rule-type (any specific rule or all rules). For a global trigger, create a logic app with an incident trigger and create an automation rule to call the Playbook for all rules. 

[#5]

Andrew, thanks, this is getting me closer to my answer!
So my new question is: how to create an automation rule to trigger on all incidents.
eg. is this a Sentinel rule that:

1. queries for all incidents

2. apply automation to call the playbook

3. extract the incident ID

4. process playbook logic as needed.

Or do you mean something else by 'create an automation rule to call the playbook for all rules'?

Once I understand what you mean by this I should be on my way.

Is there an example of this somewhere?
It seems to me it's a 1 or 2 step process but I don't quite get it yet.

[#6]

I would start by creating a logic app with just a Sentinel incident trigger. Save the app so it can be linked in Sentinel. In the Automation blade create an Automation rule. This will default to "Rule name contains all". Add a Playbook action calling your new logic app.

There are some additional steps to grant Sentinel access to trigger logic apps. This adds the Sentinel Automation role to the resource group of your workspace. Look in settings for setup UI and instructions.

Now your logic app will start being triggered by every new incident. Now you have a good mechanism to start adding activities and testing the logic app. Using "run trigger" doesn't work with triggers that require input.

Beyond that I recommend importing some sample Logic Apps from the Sentinel repo for comparison. That initial trigger may not bring in all of the data you want/need. You can run secondary activities from the Sentinel connector. It is not uncommon to see a Sentinel trigger followed by a Sentinel activity; like Get an entity, or Get Incident. Sometimes those activities pull additional information or present it in a more useful way. There is also a Azure Monitor connector that can read data from the workspace directly.

[#7]

THANK YOU ANDREW (and everyone)!!! I think I get it now. Great explanation.

Funny thing is I'm quite fluent with many of the Github playbooks but I've never used this automation feature from within the playboks - I've successfully imported/fixed over 30 of them in my Azure lab.

If you have any recommended training with playbooks specific to Sentinel I'd be interested.
Clearly my self-learning on this topic contains some gaps.

[#8]

I haven't seen any specific training on Logic Apps for Sentinel. As you have seen, every connector/activity has its quirks. The Automation Rules are new and most of the GitHub examples are using the alerts trigger. Logic Apps are all about trial and error.

Check out the run after feature if this is new...super cool.

Run After: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-exception-handling#customize-run-after-...
Logic Apps Learning Path: https://docs.microsoft.com/en-us/learn/paths/build-workflows-with-logic-apps/

[#9]

Interesting I didn't know run after was new.
I saw that in the json for all the rules but the GUI exposure maybe is the new piece?

One thing I'd like to have as a feature is an END operator, or a 'fail silently'.
For example I don't like to see a 'failed' result if one parallel branch of my logic app fails and the other 3 branches succeed.
I could use an if/then condition but I was hoping there was a way to end silently w/o failing.

(that learning path is super basic, but thanks for sharing)

[#10]

If anyone needs the exact steps I took to convert my playbook from a user-triggered (alert based) playbook to a 'global automation' (incident based) playbook here they are:

(warning, there is a cost to using automation rules, so if you trigger a lot of incidents you might want to keep tabs on the charges)

How to convert an 'Alert' triggering playbook to an 'Incident' triggering playbook with a 'global automation rule' that will trigger for all of your incidents.

1. Clone your old 'Alert triggering' playbook
2. Replace the first logic app operator (the 'Sentinel alert' operator) with the 'Sentinel Incident' operator.

3. Create an automation rule as shown in the screenshot below.

4. Review ALL variables - if you see errors, then just delete and replace the variables so they are properly 'linked'.

Optional: If you're using a parser operation to extract a field like 'entity', then your json parser will need to be updated.

Optional: update incident arm id in any of your remaining Sentinel logic operators.

Visual description of the steps above:

[#11]

Don't forget to check the rest of your Logic App to make sure you were not using dynamic data from either the trigger or action you deleted. Not saying why I know to do this ;)

[#12]

Thanks Gary, I've added a step #4: review ALL variables.

I know exactly what you're referring to!

In general when you replace any logic app containing variables it's good to review all 'downstream' logic to ensure it's not affected by the change.