Make "Mandatory" Tasks required for Incident Closure

The request here is to make Tasks set as "Mandatory", required for Incident closure.
 
Currently, Tasks that are Mandatory only dictate Phase changes. In order to enforce Task completion a script must a created or a Task must be added as part of a Workflow.

The following should be true:

1. All Tasks set as "Mandatory" must be marked completed before an Incident can be closed.

2. All Incident Fields present on a Mandatory Task, must be updated/selected before that Task can be marked complete. Then all Mandatory Tasks must be marked complete, before an Incident can be closed.
 
3. All Tasks set as "Optional" do NOT have to be marked completed before an Incident can be closed.
 
This ensures that Analysis is performed as directed in a Task, and that product of that Analysis be captured in the appropriate Incident Fields present on that Task. 

Tasks do not necessarily need to be completed in order (serially in workflows they must be completed in order), so if a Field/Analysis cannot be performed at that time, an analyst is free to work on other present tasks (the designer/lead may wish to move Tasks in a more appropriate Phase/Phase Order based on feedback.)
  • Guest
  • Mar 31 2018
  • Planned for future release
  • Attach files
  • Admin
    Brenden Glynn commented
    20 Dec, 2019 06:26am

    In the interim while we work on an a polished platform feature. Have a look at my solution posted on the Community, where I used one Rule and Script to achieve this:

    Mod Con: Enforce Completion of Mandatory Tasks before Incident Closure

  • Guest commented
    21 Nov, 2019 10:29am

    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)

  • Admin
    MARTIN FEENEY commented
    20 Nov, 2019 10:49am

    Agreed, mandatory comes with a price, thats part of the discussion for sure.

  • Guest commented
    20 Nov, 2019 10:43am

    Hi Martin,

     

    yes, I'm aware about that, thanks!

    I just wanted to enrich this discussion a little to make sure we all understand the implications of "mandatory" things and that this not only solve issues, but also might create new ones. ;)

  • Admin
    MARTIN FEENEY commented
    20 Nov, 2019 10:38am

    Hi Constantin, thanks for the feedback. In the more tolerant process you describe, this would be achieved today by making all tasks optional, so seems like this would be possible from a playbook design perspective already. If you have this type of process, then enforcing mandatory wouldn't impact you unless your playbook design was using mandatory.

  • Guest commented
    20 Nov, 2019 09:58am

    Overall I like the idea of mandatory tasks, I really do, however I'm not a friend of setting strict boundaries for users. Some of you might have worked with SAP and there you can have mandatory fields, mandatory transactions and many other capabilities to restrict the user from providing the correct (letters only, numbers only, ...) input.

    I usually get feedback from users that this not only reduces the potential "own thinking", because every task and field is put into a "restricted box" but also the developer of the playbook/process has not thought about potential other outcomes and now incidents are in a loop or modal windows cannot be closed.

    While I was under the impression years ago that we have to nail down each and every step in the process I'm now much more in favor for an open solution, which basically allows anything. If you need specific details, provided (multi-)select fields for categorisation. If you provide dedicated tasks for a certain incident category, provide a simple way out for unknown / unexpected use cases. Think about all the different versions you created of your playbook just to change it again, because of a new detail, you want to cover.

    Apart from the technical implications and issues (you have do implement feedback faster, because your design faults will have an impact on incident solving), think about the implications for the users: We restrict things, because we do not trust you to deal with the system properly. So we build you fences, which stop you from dealing with the issue properly.

     

    In the end it is a trade off/question of the following things:

    - Are your users capable of dealing with an open system?

    - Do you trust your users to use the application properly?

    - Do you provide sufficient guidance on the process, the tasks and the fields?

    - Are users used to "locked down" applications, which do not give them rights to use things differently?

    - How much more / less support you need to give users, if the mandatory tasks are enabled / are not enabled?

  • Admin
    MARTIN FEENEY commented
    19 Nov, 2019 04:18pm

    Hi James, To clarify what I think you're saying, that the mandatory check would allow some fast track completion of those mandatory tasks, not force users back into the task list to do so ?

    Hi Pat, I think I'm clear on your position.

  • Guest commented
    19 Nov, 2019 03:17pm

    Urgently Needed. Will allow for closure of FP's without having to complete the whole playbook (current rule we have in place to stop skipping tasks)

  • Guest commented
    19 Nov, 2019 01:50pm

    I would like this feature enabled. For me, the Mandatory Yes-No Option of tasks are meaningless without enforcement. If a task is set to "Active" & is Not Complete, I'd expect it to be resolved by the analyst or responder.

     

    In regards to the consequences I'd argue that the Task Objects should allow for Rule creation and individual Resilient Administrator or Playbook builders to set their own conditions. 

     

    Within our environment built out over the last 2 years we've created multiple scripts that can adjust the values of Tasks, invoked automatically from rules.

     

    In keeping with the specific concern of False Positive, my team has created a Workflow that modifies the values of an incident. So in the playbook designer if Incident Type "A" is included and the Value does not equal False Positive, certain tasks/fields/workflows/message destinations are invoked by the Automatic Rule and set to Active.

     

    However upon the change of that value to False Positive, this sets those conditions to False, removing them from the Active Task menu regardless of completion, and adding new Active Tasks. It is my intention for those tasks to be Mandatory and reviewed or actioned by my team.

     

    However if the task itself has a "Mandatory" setting, but nothing to enforce it, the designation has no meaning without strict oversight that could be added programmatically.

     

    Plugging another Idea for Conditionally required fields based on the incident's current values, this would be helpful in ensuring that the intentions of the Playbook Designer or Incident Manager are enforced.

     

    Glad to discuss at greater length if requested.

  • Guest commented
    19 Nov, 2019 12:57pm

    Like some fields are required to close an incident, some task should be able to be fulfilled before closing an incident.

    At this moment, "Mandatory" task are not really mandatory, as you can close the incident without completing the task.

     

    We could run it manually with a workflow, but it is a complex one with RestAPI request to get the id of a Task by task name, to see if the task is completed before validation of the workflow that finish the "close incident"action.

    So having this option is a good addition to have real "Mandatory" Tasks - especially if multiple tasks could be set as mandatory.

  • Admin
    MARTIN FEENEY commented
    19 Nov, 2019 12:26pm

    Can we ask everyone with an interest in this feature, whats your thoughts about how we enforce it ?

    We could ship an update that enforces it, but what about the scenarios today where users have been able to close without this.

    • Incident suddenly confirmed as false alarm, just close it and move on...

    • Existing tasks that defaulted to mandatory but we've never had to worry about them before now.

    • Regulatory tasks where local interpretation determines whats required

    Appreciate any thoughts people have on this. On paper it sounds easy, but we're concerned about these other impacts.

  • Guest commented
    20 Sep, 2019 07:42pm

    This is urgently needed.