Response Integrations

obserae detects. Acting on what it finds belongs to your orchestration platform — a SOAR, a SIRP, an automation engine, a ticketing system. This section is written for the engineer who has to connect the two, and it assumes you have never seen obserae before.

By the end of it you should be able to build an alert → enrichment → ticket playbook without asking anyone a question.

Start here: which platform, which output?

This is the first thing to get right, and the one thing most people get wrong.

obserae sends alerts through an output, configured under Connectors → Outputs. Some platforms have a matching output type; the rest receive a plain Webhook and do the work on their side. There is no “n8n output” and there does not need to be one — the n8n node runs inside n8n and listens to a webhook obserae sends.

Every one of those is documented field by field in Outputs.

What obserae does, and what it does not do

obserae is an out-of-band network detection platform. It receives NetFlow v5/v9 and IPFIX from routers, firewalls and host probes, folds those records into sessions, maps them onto an asset inventory you describe, and raises alerts. It never sees a packet payload, it is not a proxy, it is not inline, and no traffic passes through it.

It follows that obserae blocks nothing. There is no firewall API here, no NAC integration, no quarantine call, no kill-switch — not disabled, not licensed separately, not on a roadmap: absent by design. If obserae fell over mid-incident, not one packet would change course.

What it offers instead is orchestrated response: obserae supplies the evidence and the context, and your orchestrator — which does sit on the path of things, and does hold credentials for your firewall — decides and acts.

There is exactly one exception, and it is still not an action: GET /api/indicators publishes the list of public addresses obserae’s own rules fired on. A firewall, an RPZ or a blocklist can pull that list. obserae does not push it anywhere, does not know who consumed it, and has no idea whether anything was done with it. Publishing a list is not enforcement; whatever pulls it is where enforcement lives. The MISP output is the same thing pushed instead of pulled, and is no more an action than the feed.

Say this out loud when you present the integration internally, because it is the first thing a network team asks: turning obserae off cannot break connectivity, and turning it on cannot block anything.

The two directions

An integration with obserae has two halves, and most playbooks use both.

  OUTBOUND — obserae speaks first
  ┌──────────┐   alert.fired      ┌──────────────┐
  │ obserae  │ ─────────────────► │ orchestrator │   a playbook starts
  └──────────┘   signed webhook   └──────────────┘

  INBOUND — the playbook asks
  ┌──────────┐   GET /api/…       ┌──────────────┐
  │ obserae  │ ◄───────────────── │ orchestrator │   it needs to decide
  └──────────┘   Bearer token     └──────────────┘

Outbound is an output destination: a signed webhook, or one of the nineteen destinations obserae speaks natively (Slack, PagerDuty, syslog, Splunk HEC, Elasticsearch, TheHive…). The alert carries its own evidence — named columns, the query that produced it, and the asset context of every address in it — so a great many playbooks never need to call back at all.

Inbound is the REST API, and specifically its SOAR profile: fourteen operations a playbook calls to enrich an address, to ask whether a flow was allowed, or to see what a host has been doing. This is the half that makes obserae worth keeping in the stack — an analyst’s questions, answered from a playbook.

Two properties are worth knowing before you design anything:

The rest of this section

Connectors — Shuffle · n8n · Cortex XSOAR · Splunk add-on

Recipes (no connector needed) — Tines · Torq · Microsoft Sentinel · TheHive + Cortex