Microsoft Sentinel
Cloud and workloads

Use Tasks to Manage Incidents in Microsoft Sentinel in the Azure Portal

In brief

The article now separates analyst and workflow-creator scenarios, revises playbook examples, and replaces the “Next steps” section with expanded related-content links.

What Defender admins need to know

No administrator action is required. The reorganized guidance makes incident-task and automation instructions easier to find.

Summaries are generated from the documentation change itself.

Documentation change

The comparison below shows only the changed extract. Use the full-page view for complete context.

This article explains how to use incident tasks in Microsoft Sentinel to standardize and track the steps your team follows when triaging, investigating, and responding to incidents. You can add tasks manually, or automate task creation by using automation rules and playbooks.

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. With this standardized process, 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.

When to use incident tasks

Incident tasks are useful in the following scenarios:

  • 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.

Incident task management scenarios

Incident task management scenarios vary depending on whether you are an analyst or a workflow creator.

Analyst scenarios

The following scenarios show how analysts can use incident tasks during investigations.

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.

Workflow creator scenarios

The following scenarios describe how workflow creators can add and manage tasks automatically.

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:

Consider the following scenarios as examples:

  • Let playbooks add and complete tasks: When an incident is created, it will triggertriggers 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 triggertriggers 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 whether automation rules or playbooks 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 like creating tasks based on conditions,conditions or ofcreating tasks with integrated automated actions.

Next stepsRelated content