SOAR MSSP Ticket Escalation

Hey ​@Calsy, I’ve built this model for both MSSP/MDR providers directly as well as customers who act as a MSP to subsidiaries (think agencies or businesses with many subsidiaries, portcos, etc). 

The resounding answer I’ll give up front is it depends, and there are quite a few inputs that matter. A few include:

• What are the boundaries of allowed interaction on end systems (e.g. quarantining a host, resetting a user’s password) by the MSSP themselves, the automations in SOAR, additional third parties / providers, and various customer orgs / groups?
• Is the MSSP responsible for remediation or simple acknowledgement? 
• Is the escalation informational in nature or requesting action(s) to be taken? In either case, is confirmation needed? Is that confirmation manual or automated? 

The above details will drive the architecture for bidirectional syncing between platforms (or tri- or higher dimensions depending on # systems and each’s requirement...). However, regardless the flow, this typically takes one of the following shapes in my experience:

1. Customer operates directly in SOAR case via case assignment / task, if they have some level of RBAC’d access within the respective SOAR environment. 
2. Ticket is generated for external team to action (Security, IT, HR, etc) in existing ticketing platform (e.g. SNOW, Jira) and escalation is handled there (sometimes this is marked as “done” and case is closed in SecOps, sometimes it’s moved to a new state and awaits a callback automation from that system for once that incident/ticket is closed as completed)
3. Ticket is generated in external platform and bidirectionally kept in sync with SOAR case so MSSP analysts + “end user” consumers/teams stay in sync across multiple ticketing platforms as the case is moved towards resolution. 

For one-directional sync, it’s often keyed off a case stage or custom field value being set, and a singular Action taken out (e.g. Create Incident/Ticket) with the appropriate fields. For bi-directional syncs, it’s often a Job that runs on a cadence that reconciles between external platforms and SOAR.

I’ve done this with custom ITSM platforms, SNOW, Jira, other SOARs like XSOAR or Swimlane, GRC tooling like Archer, chat interfaces in SlackOps setups (Slack, GChat, Teams, etc), custom website dashboards, or even plain old email. The tooling integrated with is really agnostic to the problem and the main principle IMO is just to latch onto existing processes as much as possible, then try to seamlessly slip into those existing paths for communication / escalation. 

Let me know if this helps / if you have questions on any specific path described above.

Thanks MitchellR. If we consider the following hypothetical to brainstorm further:

• Boundaries: Host isolation, AD account revoke, log dump EDR agent, etc
• MSSP Responsibilities: Alert acknowledgement and remediation if the customer has provided required context. While it is in the stage of “Escalation” between MSSP and customer, it is the customer responsibility.
• Escalation Type: Will always be formal action requests (permission to isolate host, is this usual activity, was deletion of shadow volumes required, etc)

Based on the 3 options you have provided I feel it would be somewhere between 1 & 2. Ideally having an ITSM tool where a SecOps case would be the catalyst to create, and from there the ITSM tool is used for ticket management, and SecOps is used to perform actions (SOAR Playbooks, SIEM investigation, threat hunting, etc).  

I wouldn’t want the SecOps being closed off before the ITSM ticket is closed. So there would be some bi-direction sync required. Potentially limited to just ITSM Ticket opened, ITSM ticket updated, Ticket closed. Any specific ticket actions mentioned by customer can be alerted via teams or email integration for an analyst to be made aware.