This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
To triage, investigate and remediate an incident, the SOC analyst is required to perform a list of steps - which may be use case specific or as part of a general SOC standard. The set of steps is commonly called an incident workflow, playbook or SOPs. Formulating these processes keeps the SOC working smoothly and sets the same standards for all analysts, so no matter who is in shift, an incident always gets the same treatment and SLAs. Also, the analyst will not need to spend time on thinking about what to do or worry about missing critical steps.
While Microsoft Sentinel’s great automation capabilities help you automate the flow of those tasks or encapsulate them to one-action playbooks that can be run on-demand, they do not replace the human analyst incident-handling process.
We are pleased to continue introducing case management capabilities that help your team handle the full incident lifecycle and workflows in a unified SIEM and SOAR platform, allowing analysts to stay in context and reduce the need to pivot to external systems. This is an integral part of our efforts to empower SOC teams' productivity and effectiveness, letting you do more with less.
Now available: Microsoft Sentinel Incident tasks
- 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.
- Your SOC engineers can 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.
- Incidents – new panel: incident tasks.
- Automation rules – new action: Add task
- Playbooks (Microsoft Sentinel Logic Apps connector) – new actions: Add task, mark task as completed
We have released a first set of features but stay tuned for more additions as this feature evolves!
Follow incident tasks
When exploring the next incident in the queue to handle, analysts can already see that open tasks are waiting to be completed.
Also available from the full incident details page:
Entering the panel, a list of 6 steps appear:
The first task was added and already completed by a playbook. If the playbook failed to execute the action, the task will stay open for the analyst.
The second task has informative instructions, including links to external services and knowledge bases.
The third task has a recommended query that should be run in this kind of incidents.
If during the incident investigation process additional steps are required, analysts can add new tasks on-demand.
Ad-hoc task is added at the end of the list with the user name:
Add tasks to incidents using automation rules
With new Add task (Preview) action, automation rules can add a list of tasks for every new incident.
Apply the automation rule to a limited set of analytics rules to assign specific tasks to particular incidents, or to all analytics rules in order to define a standard set of tasks to be applied to all incidents.
In general, you can make the automation rule conditions as granular as you wish. For example, adding tasks to incidents that have certain entity type or created by Microsoft 365 Defender.
Use automation rules order to create smart tasks logic; Have an overview on all existing workflows
Tasks are added to incidents by their creation time. So Automation rules’ order and the internal order of tasks in a rule determine the order of the tasks that analyst will see. You can leverage this for smart logic. For example (See screenshot below):
- In order 1, automation rules add general tasks that must happen before specific use case tasks are added.
- In order 5-9, automation rules will add for each specific use case its own list of tasks.
- In order 10, automation rules will add tasks that should always be at the end of the analyst steps.
Lower order can also serve conditional task: for example, if automation rule in order 10 added a tag, an automation rule in order 30 can add tasks based on the tag value.
Use the filters on Action: Add task (Preview) to have a high-level overview on all the automation rules that add tasks, and all the all the analytic rules that will be impacted.
Advanced flows with playbooks
While automation rules are great for adding a plain list of tasks, playbooks can help you integrate task creation and completion in complex conditional workflows that integrate with external tools. The Microsoft Sentinel Logic Apps connector now has new actions: Add task (Preview), and Mark task as completed (Preview).
Use the Microsoft Sentinel Incident trigger to get the incident ARM ID:
Use the new task ID to mark it as completed:
Playbooks can add a task, perform the task, and mark the task as completed, so the analyst finds an incident that is already a few steps ahead.
Playbooks can add tasks based on certain conditions after collecting data and evaluating the updated investigation status. For example, when an incident is created the playbook researches an IP address that appears in an incident. If the results of this research are that the IP address is malicious, the playbook will create a task for the analyst to disable the user using that IP address. If the IP address is not a known malicious address, the playbook will create a different task, for the analyst to contact the user to verify the activity.
- Use tasks to manage incidents in Microsoft Sentinel | Microsoft Learn
- Work with incident tasks in Microsoft Sentinel | Microsoft Learn
- Create incident tasks in Microsoft Sentinel using automation rules | Microsoft Learn
- Create and perform incident tasks in Microsoft Sentinel using playbooks | Microsoft Learn