IBM QRadar SOAR

• Incident suddenly confirmed as false alarm, analyst just wants to close it and move on.
• Existing tasks we've never worried about being mandatory, all of a sudden these are all required.
• Regulatory tasks where your own interpretation decides whats needed

• Incident suddenly confirmed as false alarm, analyst just wants to close it and move on.
• Existing tasks we've never worried about being mandatory, all of a sudden these are all required.
• Regulatory tasks where your own interpretation decides whats needed

• Incident suddenly confirmed as false alarm, analyst just wants to close it and move on.
• Existing tasks we've never worried about being mandatory, all of a sudden these are all required.
• Regulatory tasks where your own interpretation decides whats needed

My thoughts on this are as follows,

Both fields and tasks can be made mandatory using a combination of rules/scripts however the overhead of managing these is prohibitive, particularly as the tasks have to be referred to by name (issues with C&P into the rule manager).

I guess the requirement for this can be primarily factored against the context of the task, for example if you have high level "runbook" tasks (ones that require an assumed level of knowledge to complete) then the case for making these mandatory may be different from "playbook" defined tasks which are more prescriptive.

Looking at some of those scenarios, how we currently manage them and some options to improve them using mandatory tasks

False Positive,

We have various checkpoints built into the tasks at various stages of the workflow for an analyst to mark as false positive, this then triggers a separate false positive workflow that contains a small set of tasks such as evaluating why the FP occurred and are any rules required to prevent them in future. Ideally here we would want to terminate the current workflow with a termination reason of "False Positive" but utilising the mandatory task completion (assuming we could select tasks in a rule) would enable us to close any subsequent tasks required.

Existing Tasks

Ideally, if you're building out runbooks and playbooks you should be engaged fully with the teams doing the incident response activity in the first place to ensure the flow is designed in line with current or proposed activity, mandatory task requirements should be discussed at this BA stage, not decided by the Resilient sysadmin therefore I personally don't see an issue with this.

Regulatory Tasks

In our sector we hand off to specific regulatory compliance teams to handle that decision making so we really only have one mandatory task for this, which is to complete the fields on a breach tab.

So, I think there are some prerequestives before mandatory tasks enforcement can be fully deployed

• The ability to directly reference tasks in the rule manager by name, as a drop down, so for example if FP is identified it can set the following mandatory tasks to "closed"
• Field logic inside tasks, as Resilient is primarily a task focused application subsequent tasks are frequently driven by responses to previous tasks, whether these are mandatory or optional should be based on decisions made in previous tasks. We can partially work with this using workflows & scripts but it's not ideal.
• Workflow loopbacks to mandatory tasks where subtasks haven't been completed.
• Logic behind the mandatory/optional options for both tasks and fields, for example "On close" for fields would work perfectly well with tasks too *if* we had logic to say, required on close for this incident type or for X, same with "required".

TLDR:

My suggestion short term would be;

Adopt the same options for tasks as fields but enable the conditional rule logic for each.

Options:

• On Close (as in on incident closure)
• Always (Mandatory)
• Optional (Optional)

• Incident suddenly confirmed as false alarm, analyst just wants to close it and move on.
• Existing tasks we've never worried about being mandatory, all of a sudden these are all required.
• Regulatory tasks where your own interpretation decides whats needed