Edit

Share via

Use tasks to manage incidents in Microsoft Sentinel in the Azure portal

  • Article
  • Applies to:
    Microsoft Sentinel in the Azure portal

One of the most important factors in running your security operations (SecOps) effectively and efficiently is the standardization of processes. SecOps analysts are expected to perform a list of steps, or tasks, in the process of triaging, investigating, or remediating an incident. Standardizing and formalizing the list of tasks can help keep your SOC running smoothly, ensuring the same requirements apply to all analysts. This way, regardless of who is on-shift, an incident will always get the same treatment and SLAs. Analysts won't need to spend time thinking about what to do, or worry about missing a critical step. Those steps are defined by the SOC manager or senior analysts (tier 2/3) based on common security knowledge (such as NIST), their experience with past incidents, or recommendations provided by the security vendor that detected the incident.

Use cases

  • Your SOC analysts can use a single central checklist to handle the processes of incident triage, investigation, and response, all without worrying about missing a critical step.

  • Your SOC engineers or senior analysts can document, update, and align the standards of incident response across the analysts' teams and shifts. They can also create checklists of tasks to train new analysts or analysts encountering new types of incidents.

  • As a SOC manager or as an MSSP, you can make sure incidents are handled in accordance with the relevant SLAs/SOPs.

Prerequisites

The Microsoft Sentinel Responder role is required to create automation rules and to view and edit incidents, both of which are necessary to add, view, and edit tasks.

The Logic Apps Contributor role is required to create and edit playbooks.

Scenarios

Analyst

Follow tasks when handling an incident

When you select an incident and View full details, on the incident details page you'll see on the right-hand panel all the tasks that have been added to that incident, whether manually or by automation rules.

Expand a task to see its full description, including the user, automation rule, or playbook that created it.

Mark a task complete by selecting its "checkbox" circle.

Screenshot of incident tasks panel for analysts on incident details screen.

Add tasks to an incident on the spot

You can add tasks to an open incident that you're working on, either to give yourself reminders of actions you've discovered a need to take, or to record actions that you've taken of your own initiative that don't appear in the task list. Tasks added in this way will apply only to the open incident.

Workflow creator

Add tasks to incidents with automation rules

Use the Add task action in automation rules to automatically furnish all incidents with a checklist of tasks for your analysts. Set the Analytics rule name condition in your automation rule to determine the scope:

  • Apply the automation rule to all analytics rules in order to define a standard set of tasks to be applied to all incidents.

  • By applying your automation rule to a limited set of analytics rules, you can assign specific tasks to particular incidents, according to the threats detected by the analytics rule or rules that generated those incidents.

Consider that the order in which tasks appear in your incident is determined by the tasks' creation time. You can set the order of automation rules so that rules that add tasks required for all incidents will run first, and only afterwards any rules that add tasks required for incidents generated by specific analytics rules. Within a single rule, the order in which the actions are defined governs the order in which they appear in an incident.

See which incidents are covered by existing automation rules and tasks, before you create a new automation rule.
Use the Action filter on the Automation rules list to see only those rules that add tasks to incidents, and see which analytics rules those automation rules apply to, to understand which incidents those tasks will be added to.

Add tasks to incidents with playbooks

Use the Add task action in a playbook (in the Microsoft Sentinel connector) to automatically add a task to the incident that triggered the playbook.

Then, use other playbook actions—in their respective Logic Apps connectors—to complete the contents of the task.

Finally, use the Mark task as completed action (again in the Microsoft Sentinel connector) to automatically mark the task complete.

Consider the following scenarios as examples:

  • Let playbooks add and complete tasks: When an incident is created, it will trigger a playbook that does the following:

    1. Adds a task to the incident to reset a user's password.
    2. Performs the task by issuing an API call to the user provisioning system to reset the user's password.
    3. Awaits a response from the system as to the success or failure of the reset.
      • If the password reset succeeded, the playbook then marks the task it just created in the incident as completed.
      • If the password reset failed, the playbook will not mark the task as completed, leaving it to an analyst to perform.

  • Let playbook evaluate if conditional tasks should be added: When an incident is created, it will trigger a playbook that requests an IP address report from an external threat intelligence source.

    • If the IP address is malicious, the playbook adds a certain task (say, "Block this IP address").
    • Otherwise, the playbook takes no further action.

Use automation rules or playbooks to add tasks?

What considerations should dictate which of these methods should be used to create incident tasks?

  • Automation rules: Use whenever possible. Use for plain, static tasks that don't require interactivity.
  • Playbooks: Use for advanced use cases—the creation of tasks based on conditions, or of tasks with integrated automated actions.

Next steps