Cortex XSOAR
In obserae: create a Webhook output with a signing secret for the alerts. The pack covers the inbound half — three commands a playbook calls.
| Where to get it | the Obserae pack in the XSOAR marketplace / demisto/content |
| Alert contract | obserae.alert/2 |
| SOAR profile | 1.0.0 |
Configure the instance
Base URL and an API token — see
a token for a playbook for which
permissions it needs. Test calls GET /api/status.
Three commands
| Command | Answers |
|---|---|
obserae-enrich-ip | what is known about an address: scope, ASN, country, cloud, feeds, and whether it is a catalogued asset |
obserae-check-policy | whether a flow was already allowed by the flow matrix, and if not, why not |
obserae-get-peers | who an address talked to, filtered by direction and scope, optionally as of the moment an alert fired |
The context paths are what a playbook binds to, so they are stable and documented in the pack’s own README.
DBotScore is deliberately timid. A threat-intel match comes back suspicious, never bad. obserae reports what feeds say; it does not judge an address. An analyst auto-escalated on a Tor entry stops trusting the integration quickly, and a timid score is easy to raise locally while a bold one is hard to undo.
The example playbook
A segmentation-triage playbook ships with the pack. It asks the flow matrix first, on purpose: a conversation the matrix already allows is a detection-tuning ticket, not an incident, and sending it to an analyst as an incident is how a queue fills with noise.