HIIH loop step: Retrieve
What HIIH delivers, and the first integration
01 · WHAT HIIH DELIVERS, AND WHAT IT DOESN'T
Name the output that is real for the deployment.
| Output form | What HIIH does with it today |
|---|---|
| Surface Console | Inspect Findings, related observations, artifacts and available replays in the Surface Console. |
| STIX 2.1 over TAXII 2.1 | Available by engagement: structured Findings and indicators exposed as STIX 2.1 objects for a CTI platform or SIEM to pull on its own schedule. |
| MCP interface | Expose selected Findings and investigation context to authorized tools that query it. |
| API | Programmatic pull of Findings and indicators for authorized integrations, scoped per deployment. |
| Briefing | Briefing material drawn from analyzed activity, which your team or your partner delivers as an operational or executive briefing, when the engagement includes it. |
| Detection content | Operational analysis produced from observed activity and backed by OHIIHO Research — where engagement material supports it. |
| IOC list (CSV) | Structured indicator list, retrievable on your schedule. |
| MISP-compatible feed | Served as a MISP-native JSON feed per deployment. Not yet proven ingested end-to-end by a production MISP instance. |
| CERT evidence pack | Assembled and governed for a specific mission, not shipped as a standing pack. |
| SOAR action | Runs in the customer’s own SIEM or workflow; HIIH does not drive a universal native response. |
| Outbound push into your stack | Not something HIIH presents as a feature — delivery is pull-based. |
HIIH starts with the workflow that creates value for the mission. A first integration does not need six connector projects — it needs one working pull path, a clear object shape and a route back to the richer context.
Audience workflows
How each team uses a delivered Finding is covered on its own page
SOC and CTI use is detailed on SOC & threat intelligence, the managed-service motion on Partners, and the CERT / government path on CERT & government — rather than repeated here.
02 · FIRST INTEGRATION SEQUENCE
Start with one useful path.
- Select the use case — early warning, access-validation monitoring, deep operating-system engagement, SOC enrichment or MSSP enablement.
- Define the output — Finding family, minimum summary and observed facts, severity/confidence mapping, routing fields, data that must remain only in HIIH, retention and access expectations.
- Choose one destination — prefer the MCP or API pull path already in place. Do not start with a connector matrix.
- Configure and test — using a controlled event, not a promise that a real advanced adversary appears during the first deployment.
- Confirm end to end — that the event reached the Surface, an Observation and Finding were created on the tested path,
finding_idwas preserved where expected, the destination retrieved the payload, and no data was exposed beyond the agreed scope. - Operate and learn — review signal quality, analyst action and integration friction.
The first deployment proves the operating model with a controlled end-to-end event. It does not guarantee the arrival of a particular adversary or campaign during that period.
Success is one Surface deployed, one path live, analysts trained, at least one Finding reviewed, responsibilities documented and a next-stage decision defined.
Boundaries & responsibilities
Ownership, containment and data boundaries live on the Trust page
Who operates what, how integration avoids widening the blast radius, and how data is handled are defined at diligence depth on Trust — see responsibilities, production separation and data handling.