SOAR MSSP Ticket Escalation

Question

Hi all,

I wanted to understand how the the winder SecOps community has managed ticket management in a MSSP context. As an example, as a MSSP, and if there is a need to escalate a ticket to a customer, what method have you found worked the best?

My initial thoughts would be the have a manually initiated playbook by the analyst summarise and escalate the alert as a servicenow ticket to the client, as well as sending a teams notification.

A flow might look something like this:

Triage & Investigation → Escalation Required (Additional client information needed/approval for action) → Playbook to mark case as paused and a notification is sent to client which creates a SNOW/Cherwell ticket → Client updates ticket → case SLA resets and internal analyst is notified via assignment of internal SNOW ticket.

Obviously the above would have several integration points, but that is my high level thinking.

What has worked for others would be greatly appreciated.

MitchellR · Answer

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 isit 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:Customer operates directly in SOAR case via case assignment / task, if they have some level of RBAC’d access within the respective SOAR environment.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)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.

Sign up

Login with SSO

Login to the community

Login with SSO