Open-source alternative to Microsoft Sentinel playbooks

Before you rebuild anything, export each playbook as an ARM template and list every Logic Apps workflow and every API connection it references. Microsoft describes playbook templates as ARM templates that contain a Logic Apps workflow and API connections, so the connection resources in the template show which external systems and identities each playbook uses. Record the trigger, the actions, the credentials or managed identity behind each connection, and the scope it runs under. Note which playbooks run from automation rules and which run manually, because the trigger model changes how you rebuild them in Shuffle.

• Workflows: List each Logic Apps workflow with its trigger type and its action sequence.
• API connections: Record each connection resource, its connector type and the account or identity it uses.
• Secrets: Identify every key, token or certificate that a connection depends on, and where it is stored today.
• Triggers: Mark which playbooks start from Sentinel incidents or alerts and which start by hand.
• Owners: Name the team that depends on each playbook so you can test with them.

Confirm the full list with your Azure administrator, because connections can exist without being visible in the portal view you usually check.

Enrichment playbooks usually query identity and asset data when an alert arrives, such as user lookups in Microsoft Entra ID, device or host context, or reputation checks against threat intelligence. In Sentinel these run through the Microsoft Entra or Azure connectors inside the Logic App. In Shuffle, the same lookups are usually built as an OpenAPI app when the vendor publishes a specification, or as a Python app with the Shuffle app SDK when the logic needs custom parsing. For a simple REST call with a known endpoint and token, an HTTP action in the workflow is often enough.

• Entra lookups: Replace the Entra connector with an HTTP action or an app that calls the Microsoft Graph endpoints your playbook uses, with credentials stored in Shuffle.
• Threat intelligence: Use an OpenAPI app where the provider publishes a specification, and a Python app where responses need transformation.
• Asset context: Map inventory sources, such as your CMDB, to a small app or HTTP action that returns the fields the analyst needs.
• Credentials: Store each token in Shuffle's app authentication, and confirm the encryption modifier is backed up before go-live.
• Output shape: Keep the enriched field names identical to the Sentinel version so downstream steps and analyst notes still match.

Test each lookup against a sample alert and compare the returned fields with the current playbook output.

Ticket sync playbooks create or update a record in a service desk when an incident is raised, and write status changes back to Sentinel. Microsoft's guidance lists bi-directional sync with ticketing systems such as ServiceNow as a recommended use case. In Shuffle, ServiceNow is typically covered by a prebuilt or OpenAPI-based app for its Table API, or by HTTP actions where your instance requires custom fields. The harder part is the return path, because Shuffle must receive status changes from the ticketing system, which usually means a webhook or a scheduled workflow that queries for updates.

• Create and update: Rebuild the create action with an app or HTTP call that maps severity, assignment group and description fields.
• Return path: Decide how status changes come back, using an inbound webhook trigger or a scheduled poll, and confirm the ticketing side can send them.
• Duplicate control: Store the ticket identifier against the alert so a replay does not open a second ticket.
• Field mapping: Document every custom field, because the ServiceNow schema in your instance is specific to your organization.
• Sync direction: Define which system wins when both change the same field.

Check the exact field and state mapping with the service desk owner, since a sync that looks correct in a test often fails on custom states.

Chat notification playbooks post an alert summary to a channel and often include buttons or links for analysts. Microsoft lists orchestration through Microsoft Teams or Slack among the recommended playbook use cases. Teams notifications in Sentinel use a Teams connector authenticated with a Microsoft account. In Shuffle, a Teams or Slack message is typically sent with an existing app or with an HTTP action that posts to an incoming webhook or the chat platform's API. Keep the message formatting simple at first, because interactive cards need extra work to rebuild.

• Channel targets: Replace the Teams connector with a webhook or API call to each channel, and record the channel and owner.
• Credentials: Store webhook URLs or bot tokens in Shuffle, and avoid embedding them in workflow text.
• Message content: Rebuild the alert summary fields first, then add links back to the Wazuh dashboard or case.
• Interactive elements: Treat approval buttons as a separate project, because they need a return path that Shuffle must handle.
• Rate and failures: Add an error branch so a failed post does not stop the rest of the workflow.

Confirm with each channel owner which alert types they must see, since notifications are often reduced during migration.

Response playbooks take action on an entity, such as disabling a user, isolating a device or blocking an indicator. Sentinel often calls Defender or Entra actions through their connectors. Each action changes live systems, so the rebuild needs more verification than the lookups. In Shuffle, response actions are normally built as an OpenAPI app or Python app that calls the target platform's API with a dedicated service identity. Limit the permissions to the minimum each action needs, and keep a manual approval step for disruptive actions until the team trusts the logic.

• Target APIs: Replace each Defender or Entra action with an app or HTTP call, and confirm the endpoint permissions with the platform owner.
• Service identities: Create a separate account for Shuffle with only the scopes each action needs.
• Approvals: Add a manual approval branch before disruptive steps such as account disablement.
• Dry runs: Test each action in a non-production tenant or with a test account first.
• Audit trail: Log each action with the alert identifier, so the outcome matches your incident record.

Confirm with your security operations lead which actions must stay automatic, because some response steps may still need a human decision after migration.