Wire one verdict. Branch the policy.
One deterministic verdict, a stable enum, named signals. Your SOAR playbook reads recommended_action or a specific signal name; your SIEM enrichment reads the same shape. No per-vendor branching in your code.
- Stable wire enum
- One shape, every IOC
- API-first, no agent
- SIEMenrich the event
- SOARbranch the playbook
- EDR / XDRisolate the host
- SWG / DNSdeny · sinkhole
Hand-stitched integrations, a fork per IOC type, opaque scores.
Three failure modes show up in every SecEng integration. None of them are your bug, and all of them are your pager.
Reputation feeds in tab-separated value (TSV) files, threat intel in vendor-specific JSON, AV verdicts as score arrays. Stitching them is hours per integration and weeks of edge-case debugging.
Domain, IP, ASN, CIDR and SHA256 each come back in a different shape. Your playbook forks into separate parsing and separate branch logic to maintain for every indicator type.
Every vendor's score rides a different scale. You end up branching on a number you cannot explain in a ticket or defend in a review.
Stop branching on scores. Branch on the contract.
POST /enrich returns verdict, risk_score, recommended_action and a signal hierarchy. recommended_action is a stable wire enum; signal names are slugs you can branch on.
if vt_score > 8: block()elif abuse_confidence >= 75: block()elif otx_pulses > 3: escalate()# one branch per vendor, forever
Every vendor a different field and scale. You own them all.
if recommended_action == "block_domain"if "co_tenant_with_malicious" in signalssame shape · Domain · IP · ASN · CIDR · SHA256
Branch on the enum. The code ages forward.
The enum is part of the contract, not a per-deployment convention. One parser holds across every IOC type, so wiring a new branch never means a new mapping layer.
Score-first decisions. Signal-level policy. Verification at scale.
Security engineering owns the wiring. Three jobs run on the same verdict shape: the top-level score decision, the signal-level branch (POST /enrich) and the bulk replay (POST /enrich_bulk).
Branch on the verdict and risk score first.
The common case: read verdict, risk_score and risk_level, then return block_domain, alert or allow.
POST /enrich returns a deterministic verdict, a 0-100 risk_score and a risk_level band. Your playbook condition node branches on these top-level fields directly: block_domain over your threshold, allow under it, alert in between. Most decisions never need to go deeper.
- POST /enrich
- risk_score · risk_level
- block_domain · alert · allow
Drive playbook decisions from signals, not just scores.
When the score is too coarse, drop down and branch on a specific named signal, not just a threshold.
When verdict and risk_score are too coarse for a policy, branch on the named signal itself. Hard, soft or observational routes per your policy.
- Managed by an Attacker Group
- Fast-Flux Behavior Detected
- High DGA Score Detected
- POST /enrich
- decision feed
Re-check thousands of SIEM decisions in one fast call.
Bulk-feed large batches of SIEM verdicts and surface the false positives and false negatives buried in them, at high volume.
POST /enrich_bulk scores thousands of decisions in a single call. VerdictIQ flags FP, FN, decision inconsistencies and IOCs whose risk profile shifted since the original decision. Same audit trail, built for high-volume log-pipeline batch jobs.
- POST /enrich_bulk
- FP/FN feedback loop
- audit replay
Engineer-friendly output, identical for every IOC type.
Domain, IP, ASN, CIDR or SHA256: POST /enrich answers in the same shape, with the same field names and the same enums. You write one parser and one set of branches, not one per indicator type.
Send a domain, an IP, an ASN, a CIDR or a SHA256 and the response comes back with identical fields in identical structure. The parser you write never forks per indicator type.
verdict, risk_level and recommended_action (allow, monitor, alert, block_domain, escalate) are closed enums with stable field names. Your condition node reads the same keys for every IOC, and you can unit-test those branches.
Scoring is versioned: pin a version for byte-stable reproducibility, and breaking changes ship as a new version, never a silent retune. Signals are additive: new ones appear over time, but existing slugs are not renamed or repurposed under your branches.
“Write the parser once. A domain, an IP and a file hash all come back the same.”
A SIEM hook, a SOAR step, an enforcement push. No console.
VerdictIQ is API-first. The same verdict enriches a SIEM event, drives a SOAR condition node, and triggers a block at the EDR, SWG or DNS layer that owns enforcement. One shape, every surface. No agent on the endpoint. No appliance in the rack.
The SIEM enrichment hook (custom command, search macro, integration app) calls POST /enrich on the IOC, and every modern SOAR exposes an HTTP action that reads recommended_action or a signal slug. Your playbook reads the same fields no matter which signals fired underneath.
The verdict fans out to the surface that owns the block: EDR/XDR isolate or quarantine, SWG category deny, DNS sinkhole. SecEng wires the contract once; the same enum drives every downstream action across detection, automation and enforcement.
Latency, rate limits and timeout behaviour are documented; wire your playbook to fail-open or fail-closed per policy.
All vendor names and logos are the property of their respective owners. Listing indicates API compatibility, not partnership or endorsement.
Wire one branch. Read the enum.
Get an API key. Pick one SOAR playbook condition or one SIEM enrichment hook. Wire POST /enrich. Read recommended_action. Move the second wiring when you have proof on the first.