Playbooks
The ten incident-triggered enrichment playbooks: what each answers, which table it writes, typical latency, and the automation-rule pairing that makes it fire.
On this page (4)
Playbooks Documentation
All ten playbooks use the Microsoft Sentinel incident trigger: they read entities from an incident, call the Whisper API, write results to the custom tables, and post a summary comment back on the incident.
Running a playbook manually
Open an incident → Actions → Run playbook → pick the Whisper playbook. Results appear as an incident comment, typically under a minute; BGP history takes up to ~90 seconds.
Playbook reference
| Playbook | Input entities | What it answers | Writes to | Typical latency |
|---|---|---|---|---|
Whisper-ExplainIP | IP | Is this IP a threat? Score, flags, feeds | WhisperThreatIntel_CL | < 1 s |
Whisper-ExplainDomain | Domain | Is this domain a threat? | WhisperThreatIntel_CL | < 1 s |
Whisper-ExplainASN | ASN | Network-level reputation | WhisperASNReputation_CL or WhisperThreatIntel_CL — UNVERIFIED | < 1 s |
Whisper-ExplainNetwork | IP and/or domain | Threat + infrastructure combined | WhisperThreatIntel_CL and WhisperInfraContext_CL | ~1 s |
Whisper-DiscoverCoHosted | IP | What else is hosted on this IP? | WhisperInfraContext_CL | < 1 s |
Whisper-GetInfraChain | IP + domain | Full IP↔prefix↔ASN↔domain relationship chain | WhisperInfraContext_CL | ~1 s |
Whisper-GetWhoisHistory | Domain | Registrar/registrant/nameserver changes over time | WhisperHistory_CL | ~2 s |
Whisper-GetBgpHistory | IP | Routing origin and prefix changes over time | WhisperHistory_CL | up to ~90 s (async: posts an acknowledgment, then results) |
Whisper-BatchEnrich | All IPs + domains on the incident | Bulk threat verdicts | WhisperThreatIntel_CL | ~300 ms per indicator |
Whisper-CheckAsnReputation | ASN | Reputation score, threat density, prefix count | WhisperASNReputation_CL | < 1 s |
Where the Writes to column comes from. It is derived from the Filled by column of Data Reference, which is the only published statement of which playbook family fills which table. Whisper-ExplainASN is marked UNVERIFIED because it belongs to both families named there — it is an explain playbook and an ASN playbook — and no published artifact settles which table it writes. It is not a guess we are willing to publish as fact: a detection built on the wrong table returns nothing and looks like a clean environment.
All playbooks retry transient API failures with exponential backoff (3 attempts) and log errors without failing the incident workflow.
Recommended automation-rule pairings
A sensible starting point — one automation rule per analytic rule you enable:
| When the incident comes from… | Run… |
|---|---|
| C2 Communication Detection | Whisper-ExplainIP |
| Tor Exit Node Communication | Whisper-ExplainIP |
| Newly Registered Domain on Threat ASN | Whisper-ExplainDomain |
| Co-Hosted Malware Cluster Detection | Whisper-DiscoverCoHosted |
| ASN Reputation Degradation | Whisper-CheckAsnReputation |
| BGP Route Anomaly with Traffic Spike | Whisper-GetBgpHistory |
| Domain Registrar Change Anomaly | Whisper-GetWhoisHistory |
| SPF Record Unauthorized Include | Whisper-ExplainDomain |
| Any multi-entity incident | Whisper-BatchEnrich |
Each rule: trigger When incident is created → condition on the analytic rule → action Run playbook. This needs the one-time permission grant in Configuration.
Watching the integration
Whisper-BatchEnrich is the heaviest playbook — it makes one API call per indicator on the incident, so an automation rule wired to every incident type multiplies fast. Start by scoping automation rules to high-severity incidents. Invocation counts, latency, and error rates are all visible in the Incident Enrichment Audit workbook.