Managed security service providers (MSSPs) and organizations that oversee multiple security teams will often have to manage multiple tenants of Microsoft Sentinel. In this situation, it’s inefficient and overwhelming to switch between instances in order to record and monitor changes to incident tickets. For MSSPs, this model limits growth potential because each analyst is limited by the number of clients they can manage.
To solve this, D3 Security developed a solution that enables bi-directional sync between Microsoft Sentinel and D3 Smart SOAR. With this solution, users can consolidate individual tenants of Microsoft Sentinel into a single instance of Smart SOAR. Any changes made to incidents within Smart SOAR are reflected in Microsoft Sentinel, and changes made to incidents in Microsoft Sentinel, are reflected back in Smart SOAR. This keeps teams working on different platforms and at different times on the same page. If one makes an update to a ticket, it’s reflected in the incident on the other platform. This makes it much easier for MSSPs to provide co-managed SIEM services, even when using a SIEM (or SIEMs) that does not offer multi-tenancy.
The Challenge
True bi-directional sync occurs when two platforms communicate changes to each other. Each platform needs the ability to send changes, receive that data, and implement the changes. This has posed a challenge to established SOAR companies because they do not have control over the product development of partnering technologies. Engineers at D3, however, have found a way to achieve the same desired outcome of bi-directional sync while only utilizing one-way communication from Smart SOAR to Microsoft Sentinel.
The solution combines multiple features only available within Smart SOAR to push updates to Sentinel and monitor existing incidents for changes that need to be made within Smart SOAR. All of this functionality operates behind the scenes, with no impact to the analyst’s day-to-day.
Part 1: The Fields to Synchronize
Together with one of our UK-Based MSSP clients, we identified five key fields that needed to stay synchronized between Smart SOAR and Sentinel. They were:
- Incident status,
- Owner,
- Severity,
- Classification, and
- Notes.
Part 2: Synchronizing Smart SOAR to Microsoft Sentinel
The first challenge was to update Microsoft Sentinel incidents whenever changes to key fields are made within Smart SOAR. Incident status, owner, and severity are quite straightforward. They rely on a feature within Smart SOAR called Trigger Workflows. Trigger workflows activate when certain conditions are met within an incident. Within Smart SOAR there are five scenarios where a trigger workflow can execute. They are:
- On Incident Close
- On Incident Reopen
- On Incident Change
- On Incident Status Change, and
- On Incident External Action
On Incident Change monitors incident fields such as the owner, severity, and notes. By adding a conditional task to this trigger, we can make the relevant update to Microsoft Sentinel when the condition is met. Similarly, the On Incident Status Change trigger links to a command that updates the Microsoft Sentinel incident with the latest status.
Keeping incident classifications up-to-date uses incident trigger workflows as well. However, it also uses a second feature within Smart SOAR, Incident Dynamic Forms. Dynamic forms define the structure of incidents within Smart SOAR. Platform engineers can define which fields are required to be completed during an investigation. In this case, fields called Classification, Classification Reason, and Classification Comment were created. In Microsoft Sentinel, each classification comes with unique options for classification reasons. In Smart SOAR, the drop down list is dynamically updated depending on which classification is selected in field 1.
Once these fields are selected and the incident closed, the On Incident Close path triggers and the corresponding classification values are collected from the incident dynamic form and pushed to Microsoft Sentinel.
Synchronizing Microsoft Sentinel to Smart SOAR
The second challenge is to update the incident within Smart SOAR when changes are made to the incident in Sentinel. Since there is no way to configure Sentinel to send specific incident changes to Smart SOAR, D3 engineers needed to figure out a way to monitor Sentinel incidents for relevant changes and update the corresponding incident within Smart SOAR.
This was achieved using our scheduled incident ingestion command. Inside Smart SOAR, alerts are ingested via scheduled GET requests made by Smart SOAR. These GET requests can either be for events or incidents. This maps to most SIEM structures, where they ingest logs, create alerts, and then consolidate those alerts into incidents. By mimicking that structure, users can determine if they want to ingest alerts or incidents into Smart SOAR. In this case, we use the incident ingestion option with the Query Time Type field set to Last Modified Time. With this option selected, Smart SOAR will look for modifications made to Sentinel Incidents. Then, using the Update Field Mappings section at the bottom, it will update Smart SOAR incident data with new inputs.
Takeaway
The issue of multiple siloed tenants poses an issue for MSSPs and organizations that monitor multiple security teams. Their teams face complicated daily demands and their growth is limited. However, by consolidating alert queues into a single instance of Smart SOAR, these organizations can streamline their incident response and client management. However, this is challenging because not many SIEM solutions are built to keep other tools up-to-date with changes made to their incidents. This is because their assumption is that teams will work solely out of the SIEM. However, as I’ve outlined for MSSPs, this is not always the case. The engineering team at D3 has built a solution in partnership with one of our clients to enable bi-directional sync capabilities between Smart SOAR and Microsoft Sentinel. The outcome for our clients is an expanded horizon in terms of the number of customers they can serve and the number of technologies they can support. For MSSPs, this is crucial.
