Playbooks
The ten incident-triggered enrichment playbooks: what each answers, which table it writes, typical latency, and its automation-rule pairing.
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.
Key concepts: Nameserver · Tor exit node · ASN reputation.
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 — query both | < 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 |
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.