Blog Post

Microsoft Sentinel Blog
3 MIN READ

What's New: Azure Sentinel Logic Apps Connector improvements and new capabilities

liortamir's avatar
liortamir
Icon for Microsoft rankMicrosoft
Nov 30, 2020

Azure Sentinel Logic Apps connector is the bridge between Sentinel and Playbooks, serving as the basis of incident automation scenarios. As we prepare for new Incident Trigger capabilities (coming soon), we have made some improvements to bring the most updated experience to playbooks users.

Note: existing playbooks should not be effected. For new playbooks, we recommend using the new actions.

 

Highlights:

  • Operate on most up-to-date Incidents API
  • New dynamic fields are now available 
  • Less work to accomplish incident changes
  • Assign Owner ability in playbooks
  • Format rich comments in a playbook

 

 

What's new?

 

Update Incident: One action for all Incident properties configuration

Now it is simpler to update multiple properties at once for an incident. Identify the Incident you want to operate on and set new values for any field you want. 

 

Update Incident replaces the actions: Change Incident Severity, Change Incident Status, Change Incident Title, Change Incident Description, Add/Remove Labels. They will still work in old playbooks, but eventually will be removed from the actions gallery for future use.

 

 

Assign Owner in playbooks

As part of new Update Incident, it is now possible to assign an owner to an incident in a playbook. For example, based on incident creation time and SecOps staffing information (for example, from a you can assign the incident to the right shift owners:

  1. Set Assign/Unassign owner to Assign
  2. Set Owner with the Object ID or User Principal Name.

 

Post Rich Comments with HTML editor

Recently, Azure Sentinel added support for HTML and Markdown for Incident Comments. Now, we added an HTML editor to the Add comment to Incident so you can format your comments.

 

 

One identifier for working on Azure Sentinel Incidents

Previously, you had to supply 4 fields in order to identify the incident to update. New Update Incident and Add Comment to Incident require only one field (instead of 4) to identify the incident that meant to be changed: Incident ARM ID.

 

If your playbooks start with Azure Sentinel Alert trigger (When an Azure Sentinel Alert is Triggered), use Alert - Get Incident to retrieve this value.

 

Get Incident: Now with most updated Sentinel API

Alert - Get Incident allows playbooks that start with Azure Sentinel Alert Trigger (When an alert is triggered) to reach the incident that holds the alert.

 

Now, new fields are available and are aligned to the Incident API

For example, Incident URL can be included in an Email to the SOC shared mailbox or as part of a new ticket in Service Now, for easy access to the incident in the Azure Sentinel portal.

 

 

This action's inputs have not changed, but the response became richer:

 

 

 

In addition, we supplied another action called Get Incident which allows you to identify incidents using the Incident ARM ID, so you can use any other Logic Apps trigger and still get Incident details. It returns the same Incident Schema. For example, if you work with another ticketing system which supports triggering Logic Apps, you can send the ARM ID as part of the request.

 

 

 

Get Entities: names change

As we prepare for our new Incident Trigger experience, when entities will be received both from incidents an alerts, we changed the name of the actions Alert - Get IPs/Accounts/URLs/Hosts/Filehashes  to Entities - Get IPs/Accounts/URLs/Hosts/Filehashes. 

 

 

Learn more

Azure Sentinel Connector documentation

 

Updated Nov 03, 2021
Version 3.0
  • liortamir thank you for the updates. The IncidentURL was awaited and will be helpful.

    Had a request to make the When_Azure_Sentinel_incident_creation_rule_was_triggered_(Private_Preview_only) public allowing us to use it with incidents. Currently we can't map it to analytics rules and that was an issue since we are aggregating alerts into incidents.

    And for 90% of rules we don't wan't the playbook to run per alert rather per incident, so speeding this one up would be really helpful.

    Thanks again. 🙂

  • Thijs Lecomte , Great feedback! We will check that, definitely important usage. 

    Joseph-Abraham , stay tuned - this is very soon public. We are going to present new automation capabilities beginning of new year, including Incident Trigger becoming public. 

    Thanks JamesvandenBerg ! 🙂

  • Thijs Lecomte's avatar
    Thijs Lecomte
    Bronze Contributor

    Awesome changes!

     

    One question: Will support for dynamic links be added to the 'Add comment to incident' in the future?

    I would love to use a dynamic value for the value of the link.

  • liortamir The above promise of releasing the Sentinel trigger as public hasn't materialized yet.

    Sorry to say but this makes life difficult for a lot of us.

    Expecting a faster turnaround.

  • Joseph-Abraham  liortamir 

     

    I am in the middle of trying to make a decision for my MSSP on which ticketing solution to choose to integrate with Sentinel.

     

    This ticketing system will be crucial to my operations as an MSSP.

     

    What are some recommendations? Which is the easiest to deploy currently?

    I really just need to create tickets between my clients and the MSSP, would like to include automation, etc.

  • Joseph, I talked with SNOW yesterday.

    It's a minimum of 25 licenses , at 42,000 $ per year?

  • tipper1510's avatar
    tipper1510
    Brass Contributor

    We are currently using event hubs to sync incidents between Sentinel & Resilient and parsing Json to get key incident details such as the incident id. v2 of the 'Add comment to incident' allow us to use the parsed json 'incidentid'. Will this id work in place of the 'Incident ARM id' that is now required by the new v3 connector? 

     

    Many thanks,

     

    Tim 

  • SocInABox's avatar
    SocInABox
    Iron Contributor

    Question:
    The Create job automation account operator is missing a field.
    The operator doesn't contain a parameter field:

     

    But the missing field is shown here in the screenshot for this playbook.

    It appears there used to be such a parameter or this has somehow been customized to include the parameter field?:

    https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Block-OnPremADUser

     

     

    If you use the 'peek code' option, or view the json from the playbook template you can see this:

    "SamAccountName""@{substring(body('Parse_JSON')?['Name'],0,indexOf(body('Parse_JSON')?['Name'],'@'))}"
    So it appears the operator has been hardcoded to accept the 'Name' parameter??

    Was this configuration modified at the JSON level and then imported into Azure?
    Is there any documentation explaining how to configure this?
    Thank you.