Platform · IdoubleS CTM
One governed model. Built with AI, validated by people, and owned by you.
AI reads a threat report in seconds, yet its output lacks reliability, confidence and validation, and a model your SOC acts on needs all three. IdoubleS CTM gives every claim its evidence, its confidence and an analyst's decision, and keeps the result in open standards so your SIEM, EDR and AI agents consume one model instead of four readings.
How it works, at a glance
Reports become attack graphs
Upload a report or connect to an API. The AI extracts the actors, tactics, techniques, and procedures into a STIX 2.1 attack graph. Every claim keeps the passage it came from and its confidence.
Your analysts decide
Everything extracted starts as a draft. An analyst validates, supersedes or rejects it with the evidence beside the claim. The decision, its author, and the lifecycle are recorded.
One model for every team
Validated knowledge becomes native detection rules, hunting hypotheses, incident scope, test scenarios, and reports, and your AI agents read the same claims over APIs and MCP.
Threat-centric
Who would attack you, and how.
Threat actors come in long lists and reports come in prose, and neither says which of them concerns your organisation. The platform scores a curated library of actors against your business parameters and refines the reports that matter into attack graphs, the technique chain and the observable evidence beneath it. You get a short list of relevant adversaries with a rationale each, and a model of their behaviour your analysts can stand behind.
- Relevant threat actors ranked high, medium or low from your industries, regions, offerings, suppliers, and scenarios, each with its reasoning.
- Attack graphs from PDF, Word, HTML or a link, with the source passage, the rationale, and the confidence kept on every claim.
- Analyst gate per claim. Each claim is reviewed by an analyst and validated, superseded, rejected or kept for further verification, with the decision and the analyst responsible recorded.
Each technique is one claim, refined from the report with its source passage, a confidence, and the analyst's decision beneath it. Four fields and a gate are the difference between a plausible claim and a verified one, and they are what regulators, auditors, and your own agents will ask for.
Modelled the way DORA and TIBER-EU describe a critical or important function (CIF), so the same decomposition serves risk, the SOC, and the red testing team.
Asset-centric
What must be protected.
Sensors see hosts and packets, not the business function behind them, and a vulnerability score says nothing about whether an adversary can reach it. The asset-centric side models your critical business functions with their consequences, supporting systems and technical components, loads known weaknesses per component, and computes the attack vectors into each function, ranked by likelihood and severity. Risk, the SOC, and the red team then argue about one picture instead of three.
- Decompose each business context into functions, subfunctions, supporting systems, technical components, and third-party dependencies, including assets not visible to sensors.
- Map weaknesses and known vulnerabilities to each component then identify the attack vector that can reach each business function with a tier per asset.
- Assess consequences across confidentiality, integrity, availability, and access control, aligned with regulatory requirements.
The bridge
SoonWhich campaign can reach which function.
A campaign's attack graph is laid over the attack vectors of your critical business functions. The result is an exposure list ranked by adversary relevance based on motivation and intent rather than by CVSS alone, and for every actor that can reach a function, a threat scenario is recorded as a claim with its rationale and confidence.
A technique from the campaign meets an attack pattern on a supporting system, and the flag on the function is reached. The link is a claim like any other, with evidence, confidence, and an analyst's decision.
Operational layer
From model to action, for your analysts and your agents.
A report that is read four times produces four truths. The operational layer derives everything from one validated model and keeps the trace back to the claim, so a rule, a hypothesis or a test scenario can always say why it exists and which critical business function it protects. Process once, reuse everywhere.
Native SIEM and EDR rules
Detection logic derived from the graph, checked against what your environment can see, and emitted as native rules for the SIEM and EDR you run. Coverage per adversary becomes a number.
Hypotheses and incident scope
Hunting hypotheses read off the adversary's procedure, investigative questions, and incident scope in the attacker's order. Technique, log source, and event.
TIBER-EU deliverables and audit-ready reports
Threat profiles and scenarios per critical business function for TIBER-EU and DORA, reviewed and exported as PDF.
The model as data
STIX 2.1 bundles, JSON, CSV, and APIs. Our STIX 2.1 extension schema is openly published, allowing compatible STIX tools and visualizers to extend their parsers and read the full graph. Nothing stays bound to the platform.
One knowledge layer for all of them
Your own agents, or your SOC platforms, work from the validated claims over APIs and MCP. They read validated state. Change the platform, keep the knowledge.
Triage, hunting, exposure, and response
Agents of our own on the validated model, each reporting its findings for your analysts to decide on.
Deployment and sovereignty
Deployed to your requirements.
Security platforms are increasingly cloud-delivered, and regional processing is the usual answer to sovereignty. It says little about where data, models and security knowledge reside. IdoubleS CTM runs in the cloud, on-premises or air-gapped, with the AI models inside your boundary, on open standards and open-source foundations. Data, models and the governed knowledge stay in your environment, and you decide where they reside.
Availability
What is available today, and what is coming.
Relevant threat actors and threat assessment with rationale
Attack graphs from reports, evidence and confidence per claim, and analyst gate
Detection logic and native SIEM and EDR rules, and coverage per adversary
Critical business functions, asset inventory with weaknesses, and attack vectors per function
Reporting with live blocks, TLP marking, review workflow, and PDF export
STIX 2.1, JSON, CSV and API exports, and your own AI agents on the validated model
Single sign-on, multi-factor authentication, roles, business entities, and licenses
The bridge, campaign exposure mapping across your critical business functions
IdoubleS agents for triage, hunting, detection engineering, exposure management, and response
MCP server for the agents of your SOC platform, live on the validated model
Further native SIEM and EDR modules
See it on your own report
Bring one threat report. Leave with a governed model.
In a demo we refine a report of your choice, walk through the analyst gate and show the native rule it produces for the SIEM you run.
Contact
Operationalise Cyber Threat Intelligence.
Turn the reports and feeds you already receive into a governed Cyber Threat Model that your SOC and risk and management teams can act on. Tell us where you want to start.