Deputization Versus DelegationDelegating means “do this task and bring it back to me.” Deputizing means “own this process and bring me the results.”
For this article I’m going to look first at a DevOps use case, then a workload use case, and lastly a SOC usecase.
Use Case: DevOps deputising an entire process to Me
As a Sales Engineer a common workload I have is creating many cloud based POC environments. The process is quite long, and involves managing multiple platforms:
- Deploy Virtual machine instance
- Patch and update the software image
- Configure basic setting
- Allocate IP, synchronise DNS, tag the machine
- Manage asset management, billing management
- ….and lots more
It’s a long process, with lots of change management, it includes lots of other platforms. Our DevOps team don’t have the resources to manage this for all the SEs around the world, but also they don’t want to give me access to all the underlying platforms. So how do we manage this?
Answer: Deputise the process to the SE using automation to handle the workflow
Imagine a form that I can complete, that asks some very simple questions:
This data is fed into the “New Investigation form”:
- Owner: Allows SOAR to automatically find and ask my manager for approval
- AWS Region: Tells the AWS API calls where to create the POC
- Company name: Used for billing/asset/inventory control
- etc
In the next 4-5 minutes the playbook does all the processing for me, configuring, installing, modifying, tracking, etc. As this work is done for me, I can concentrate or more important thing elsewhere.
This is a great example of DevOps safely deputising a process to the SE team. I have no access to any equipment, yet 24/7/365 with no advance warning I can spin up my own POC environment in 5 minutes because I run the process but DevOps own it. DevOps only need to be involved where something goes wrong.
Consider your own work environment, are there any services your team would like to offer the business in a quicker/safer way without losing control?
Use Case: Delegate a single task
When running a POC I sometimes need help from an architect to complete 1 step of the process. I don’t want them to own the entire process, but I do desperately need their help for one bit.
A playbook can, automatically or by your choice (as with this example) assign specific tasks to a different team or a specific person.
If I chose “Assign Architect” the playbook takes the Right hand path and assigns the task to the Architect team. The investigation is now assigned to them, and only their user/team/role can progress through this task.
As this task belongs to a different team, I don’t want their workload to affect my SLA, so let’s create a specific SLA for just this task:
With Delegation, I own the overall process, but a particular task can be automatically given to another member of the team (with their RBAC, SLA), or even a completely different team, but the ownership of the workflow, all the graphs/dashboards and reports show that the work is still mine.
Use case: False positives and tuning a signature/policy: Delegate or Deputise?
Imagine a noisy IDS signature creating many False Positives every day, I need the signature/policy improving, and that responsibility might be with a different person/team.
This could easily be built as a simple Delegation, a single task in a playbook assigned to someone else, that is a spur or added on to the main workflow:
Deletation is good, delegation would work.
But if we change this and Deputise it we can get a more controlled process:
As the Analyst, by answering “Yes” the current investigation creates a new investigation, assigns it to someone else, but I can still track the progress from the original ticket, my own ticket.
In the below screenshot, I am “AndyAdmin” and I own the ticket to investigate the alert. From here I can see that a new incident was created to Tune the alert, I can see it was assigned to Laura and I can monitor the status.
This way:
- The original analyst doesn’t have to wait for tuning before they can close the investigation
- Monthly reports correctly show 2 separate tickets by the team
- Each team has cleaner/simple SLA and dashboards
- We can have 1-many relationships of investigations for tuning
- Tuning investigation can be reopened cleaner (as not linked to an investigation)
- etc
This isn’t going to win a Nobel Prize, but it is an effective way to automate the inefficient way most organisations handle assigning tickets, tasks, delegating, etc across all the different teams.
Useful?
Andy