SIEM integration in 15 minutes

Enrich firewall and proxy alerts in Splunk or Microsoft Sentinel with one API call. Clear the CDN, cloud and proxy IPs that fire false positives, and send an analyst the ones that actually need a look.

Three steps, about fifteen minutes

No connector to install, no data to ship us. Your SIEM calls one endpoint and gets back a verdict it can act on.

~2 min

1. Grab your API key

Sign up free and copy your rpt_ key from the dashboard. No card needed to start, and every new account gets full data for 15 days.

~10 min

2. Wire the API call into your SIEM

Add one POST to /lookup as an alert action, playbook step, or scheduled enrichment. The reference patterns below for Splunk and Sentinel give you a starting point to adapt.

~3 min

3. Alerts enrich themselves

Every firewall/proxy alert now carries a verdict, the provider, and an investigation hint. The benign infra clears on its own; the rest reaches an analyst with context.

What a firewall false positive looks like

A Cloudflare edge IP trips a firewall or proxy rule and looks like C2. Blocking it breaks real traffic. Here is exactly what Reput.io returns, so the analyst checks the hostname instead of chasing the IP.

POST https://api.reput.io/lookup
{ "indicators": ["104.16.132.229"] }

{
  "indicator": "104.16.132.229",
  "status": "enrichment",
  "verdict": "investigate",
  "risk_context": "CDN Security",
  "provider": { "name": "Cloudflare", "type": "cdn_security" },
  "recommendation": {
    "action": "allow_with_logging",
    "false_positive_likelihood": "high",
    "investigation_hint": "Check the HTTP Host header or SNI — the
      Cloudflare IP is just a proxy. Look up the actual domain."
  },
  "geo": { "country": "Canada", "asn": 13335, "asn_org": "Cloudflare, Inc." }
}

Verdict stays honest

CDN and cloud IPs never come back "benign" — they host customer C2 too. You get investigate with a high false-positive likelihood, not a blind allow.

The analyst gets the next move

The investigation hint says check the Host header / SNI, not the IP. That turns a 20-minute dead end into a 30-second decision.

Known-good clears itself

A public resolver like 8.8.8.8 comes back likely_benign, so your rule can auto-close it and never page anyone.

Starting points for your SIEM

Splunk and Microsoft Sentinel are the two most common asks, but the API is a plain REST endpoint, so any SIEM or SOAR that can make an HTTP call works the same way.

These are reference patterns, not tested drop-in configs. Field names, indexes and playbook wiring differ per environment, so treat them as a starting point and adapt to yours. The one thing that never changes is the API call itself.

# Splunk — enrich firewall/proxy events with Reput.io
# Alert action or SOAR playbook step. Feeds a lookup you can join on src_ip.

| inputlookup firewall_alerts.csv
| eval body="{\"indicators\":[\"" . src_ip . "\"]}"
| map search="| curl method=post
      uri=\"https://api.reput.io/lookup\"
      header=\"X-Api-Key: rpt_your_key\"
      body=$body$"
| spath input=curl_message path=results{}
| eval verdict=results.verdict,
       fp=results.recommendation.false_positive_likelihood,
       provider=results.provider.name
| where verdict!="likely_benign"
| table src_ip provider verdict fp results.recommendation.investigation_hint

One REST call, so it drops into whatever you already run:

SplunkMicrosoft SentinelIBM QRadarElastic SecurityGoogle ChronicleSumo LogicExabeamSecuronixLogRhythmGraylogWazuhPalo Alto XSOARTinesTorqShuffle

Fewer false positives on your next firewall alert

Start free and wire it into your SIEM today, or talk to us about a volume plan and a hand with the integration.