Enterprise Security Integration

Threat Intelligence framework integration

The ES Threat Intelligence framework consumes KV Store collections that match the ES ip_intel and domain_intel schemas. The add-on ships two:

Both populator searches live in savedsearches.conf and are disabled by default (AppInspect requirement). Each search queries MATCH ... LISTED_IN ... FEED_SOURCE against the WhisperGraph, outputlookups to the collection, and tags each record with threat_category = whisper so ES can surface them as a feed source.

The _time field on each record uses the indicator's latest lastSeen timestamp from its threat feed sources when available, which reflects when the indicator was most recently observed as active -- more useful for ES correlation than collection time. When no source timestamps are available (e.g. indicators not listed in any feed), _time falls back to the collection time.

Records are written using KV Store batch_save (up to 1000 per batch) for efficient bulk population. If a batch fails, the populator falls back to per-record inserts to maximise coverage.

Collection schemas

whisper_ip_intel (ES ip_intel-compatible):

whisper_domain_intel (ES domain_intel-compatible):

Enabling the populators

In Splunk:

1. Go to Settings > Searches, Reports, and Alerts.
2. Filter on app = TA-whisper-graph.
3. Edit Whisper - Populate IP Threat Intel KV Store and Whisper - Populate Domain Threat Intel KV Store -- set Enabled = true and pick a schedule (the default 0 */6 * * * runs every 6 hours).
4. In ES, confirm the feeds appear under Configure > Data Enrichment > Threat Intelligence Management.

Enrich with Whisper adaptive response action

alert_actions.conf ships the [whisper_enrich] custom alert action backed by whisper_adaptive_response.py. This lets an ES analyst (or a correlation search) enrich an indicator on demand and write the result back onto the notable event.

From a notable event:

1. Open the notable in Incident Review.
2. Actions > Run Adaptive Response > Enrich with Whisper.
3. The action pulls candidate indicators from src, dest, src_dns, and dest_dns on the notable, calls the WhisperGraph, and adds the enrichment result as a comment on the notable.

From a correlation search, attach action.whisper_enrich = 1 to the saved search to fire the enrichment automatically on each triggered result.

CIM field aliases on enrichment events

props.conf aliases Whisper-prefixed fields on whisper:enrichment events to CIM field names so notable events, RBA rules, and ES dashboards can correlate without custom extractions. The full alias table is in CIM Mapping, but at a glance:

• whisper_ip -> dest_ip
• whisper_country -> dest_country
• whisper_asn -> dest_asn
• whisper_threat_score -> threat_score, whisper_threat_level -> threat_level
• whisper_risk_score -> risk_score, whisper_risk_level -> risk_level
• all 13 whisper_is_* boolean threat flags alias to the CIM Threat Intelligence equivalents (is_c2, is_malware, is_phishing, ...)
• vendor and vendor_product are set via EVAL so CIM dashboards group Whisper data under a consistent vendor label.

The events are tagged network resolution dns, so they participate in the Network Resolution and DNS CIM data models. whisper:threat_intel and whisper:watchlist events are tagged threat report for Threat Intelligence.

Example enrichment pipeline templates

savedsearches.conf ships four disabled enrichment pipeline templates under the Example - Whisper - ... prefix. Each is a starting point: clone it, swap the placeholders, pick a destination index, and enable:

Each template's search field uses <source_index>, <source_sourcetype>, <destination_index>, and <indicator_field> placeholders that you must replace before enabling.

Graph-query macros

macros.conf ships nine macros you can reuse inside detections, dashboards, or RBA rules to keep SPL short and consistent. They are query helpers, not correlation-search thresholds:

All macros are parameterised -- the $domain$ / $asn$ / $indicator$ substitutions flow into the params argument of whisperquery, so there is no string interpolation on the way into the Cypher query.

The recommended recipe for a Whisper-powered ES detection:

1. Pick a source index -- network traffic, proxy, DNS, or whichever events contain the indicator you want to enrich.
2. Clone one of the example templates as a starting point, or write a fresh stanza if none fits.
3. Call whisperlookup (for enrichment) or one of the whisper_* macros (for graph traversal) to add Whisper context.
4. Add your detection condition as a where clause on whisper_risk_score, whisper_threat_level, one of the whisper_is_* flags, or a graph-traversal result.
5. Decide what happens on match -- write to index=risk for RBA, emit an index=notable event, or route back into your security workflow.
6. Schedule it disabled, tune it against historical data, then enable.

Worked example 1 -- suspicious CNAME chain

Goal: flag DNS queries where the CNAME chain is longer than 3 hops and the chain does not terminate at a known CDN.

index=<dns_index> sourcetype=<dns_sourcetype> earliest=-15m query=*
| rename query AS indicator
| dedup indicator
| `whisper_cname_chain(indicator)`
| where depth > 3
| lookup whisper_cdn_asns.csv asn AS whisper_asn OUTPUT asn AS cdn_asn
| where isnull(cdn_asn)
| eval risk_score=30
| eval risk_message="Whisper: suspicious CNAME chain depth=" . depth . " ending at " . cname_target
| eval risk_object=indicator, risk_object_type="other"
| collect index=risk sourcetype=whisper:risk

The depth threshold (3) lives in the SPL -- override it there, not in a macro. whisper_cdn_asns.csv ships in lookups/ and lists known CDN/SaaS ASNs for noise reduction.

Worked example 2 -- multi-feed threat IP communication

Goal: flag internal hosts talking to IPs appearing on multiple distinct threat feeds (high-confidence threat signal).

index=<firewall_index> sourcetype=<firewall_sourcetype> earliest=-15m action=allowed
| rename dest_ip AS indicator
| dedup src_ip indicator
| `whisper_explain(indicator)`
| spath threatFeeds{} output=feeds
| eval feed_count=mvcount(feeds)
| where feed_count >= 2
| eval risk_score=case(feed_count >= 4, 80, feed_count >= 2, 50, 1=1, 0)
| eval risk_message="Whisper: destination IP listed on " . feed_count . " threat feeds"
| eval risk_object=src_ip, risk_object_type="system"
| collect index=risk sourcetype=whisper:risk

The >= 2 minimum feed count is the detection threshold -- change it inline.

Worked example 3 -- co-hosting density anomaly

Goal: flag outbound traffic to IPs with fewer than 5 co-hosted domains (dedicated infrastructure pattern often used by C2 or phishing), while excluding known CDN ASNs.

index=<firewall_index> sourcetype=<firewall_sourcetype> earliest=-30m action=allowed
| rename dest_ip AS indicator
| dedup src_ip indicator
| whisperlookup field=indicator type=ip
| where whisper_cohosting_count < 5
| lookup whisper_cdn_asns.csv asn AS whisper_asn OUTPUT asn AS cdn_asn
| where isnull(cdn_asn)
| eval risk_score=25
| eval risk_message="Whisper: low-density cohosting (" . whisper_cohosting_count . " domains on " . indicator . ")"
| eval risk_object=src_ip, risk_object_type="system"
| collect index=risk sourcetype=whisper:risk

Worked example 4 -- BGP prefix conflict

Goal: monitor an inventory of your organisation's ASNs for prefix conflicts (i.e. prefixes announced by unexpected ASNs -- a BGP hijack signal).

You will need a CSV of your ASNs (e.g. a hand-maintained my_org_asns.csv):

| inputlookup my_org_asns.csv
| rename asn AS our_asn
| map search="| whisperquery query=\"MATCH (a:ASN {name: $our_asn$})-[:ROUTES]->(p:PREFIX)<-[:CONFLICTS_WITH]-(other_p:PREFIX)<-[:ROUTES]-(other:ASN) WHERE other.name <> $our_asn$ RETURN a.name AS our_asn, p.name AS prefix, other.name AS conflicting_asn LIMIT 50\" params=\"our_asn=$our_asn$\""
| eval risk_score=75
| eval risk_message="Whisper: prefix " . prefix . " announced by our ASN " . our_asn . " and unexpected ASN " . conflicting_asn
| eval risk_object=conflicting_asn, risk_object_type="other"
| collect index=risk sourcetype=whisper:risk

| map is used so each our_asn is passed through as a parameter rather than interpolated into the Cypher string.

Inline risk scores

If you do not want to write a detection and only want to react to Whisper-computed risk scores, every whisperlookup result already includes four risk fields you can alert on:

Tune the factor weights in lookups/whisper_risk_factors.csv -- each row specifies a factor name, point value, and description. Use Settings > Lookups > Lookup table files to edit the CSV without touching .conf files. See the Enrichment page for the full factor list and weights.

Example RBA trigger based on inline risk scores:

index=<source_index> sourcetype=<source_sourcetype> earliest=-15m
| rename <indicator_field> AS indicator
| dedup indicator
| whisperlookup field=indicator
| where whisper_risk_score >= 60
| eval risk_score=whisper_risk_score
| eval risk_message="Whisper risk " . whisper_risk_level . " (" . whisper_risk_factors_list . ")"
| eval risk_object=indicator, risk_object_type=if(whisper_indicator_type=="ip", "system", "other")
| collect index=risk sourcetype=whisper:risk

• Install the add-on on the ES search head (or the ES search head cluster). The adaptive response action and threat intel populator searches run on the search head.
• If you operate a separate heavy forwarder for data collection, the modular inputs can also be configured there -- see the Modular Inputs page.
• Confirm whisper_user is imported (via authorize.conf) into the ES roles your analysts use so they can run whisperlookup / whisperquery from the ES search bar.
• Add TA-whisper-graph to your ES deployment-server bundle if shipping to a distributed environment; see the Deployment Architecture page.

• Saved Searches -- full list of shipping utility and example searches.
• Macros -- every whisper_* graph macro with parameters and example output.
• CIM Mapping -- full CIM alias table and data-model coverage.
• Enrichment -- risk factor list and scoring engine.
• Search Commands -- whisperlookup, whisperquery, and the rest of the command set.