The threat-intelligence layer (Phase 3 of the system). What a rigorous researcher and a SOC team check when judging how serious an organization is: where your data comes from, whether you respect licences, whether you can exchange intelligence in industry standards — and whether you honestly separate what is genuinely ingested from what is merely planned. Evidence-first: the automation detects a signal, a human confirms a fact.
We do not promote an automated indicator (IOC) to the status of a fact without assessing the source's reputation and obtaining manual approval. A feed is a hypothesis about a threat; the confirmation is proof. The same claim ≤ proof doctrine that governs the entire ipIII portal governs the CTI layer.
The layer combines public sources (OSINT), industry CERT/CISA channels and our own telemetry. Each source has a declared data type, licensing model and integration status. We respect licence terms — commercial or restricted-use data is not redistributed against its terms.
| Source | Data type | Licence / terms | Status |
|---|---|---|---|
| CERT Polska (CSIRT NASK) | alerts, phishing campaigns, CyberTarcza domains | public advisories, per NASK terms | LIVE |
| ENISA | reports, taxonomies, threat landscape | EU publications, CC / citation | LIVE |
| CISA KEV | catalog of actively exploited vulnerabilities | US Gov public domain | LIVE |
| NVD / CVE (MITRE) | CVE records, CVSS, CPE | public, NVD JSON 2.0 feed | LIVE |
| GitHub Security Advisories (GHSA) | vulnerabilities in OSS dependencies | CC-BY-4.0 (GHSA database) | LIVE |
| Vendor advisories (MS/Cisco/Oracle…) | security bulletins, patch notes | per vendor terms | ROADMAP |
| AbuseIPDB | IP reputation, abuse reports | API key, rate limits, per licence — no redistribution | ROADMAP |
| URLhaus / abuse.ch | malicious URLs, payload hosting | CC0, per abuse.ch policy | ROADMAP |
| PhishTank | verified phishing URLs | API, per terms — attribution | ROADMAP |
| Own reports (CVD / intake) | vulnerabilities, incidents from researchers | internal, evidence-first | LIVE |
| WAF / CDN / SIEM logs | attack telemetry, patterns, injection attempts | internal, GDPR minimization | INTERNAL |
Licence boundary. A restricted-licence feed (e.g. AbuseIPDB) is used for internal prioritization, not for public redistribution of raw indicators. We treat a breach of source terms as a breach of the evidence-first principle — a source without a right of use is not evidence, only legal risk.
The key to exchanging intelligence at global scale: standards, not proprietary formats. The system is designed around open CTI standards so it can exchange data with CSIRTs, ISACs and the recipient's SIEMs without ad-hoc conversion.
Serialization of indicators and intelligence objects in STIX 2.1; distribution and subscription via TAXII 2.1 collections. STIX JSON export LIVE, TAXII server ROADMAP.
Exchange of events and attributes with MISP instances (event/attribute format, galaxy tags). Import of MISP-compatible feeds; publication to trusted communities.
Mapping of techniques and tactics (TXXXX) onto incidents and playbooks. A shared TTP language for reporting to the recipient and correlating with detection.
Connectors for Azure Sentinel (DCR/Log Ingestion API), Splunk HEC and syslog RFC 5424. Indicators and alerts in the recipient platform's native format.
Real status: the CTI data model and ATT&CK mapping are LIVE; STIX JSON export works; the TAXII server, bidirectional MISP sync and production SIEM connectors are under construction ROADMAP. We do not claim ready integrations that do not yet exist.
Every indicator passes through a deterministic pipeline. The automation assigns a signal and a confidence score; a human confirms the fact for CONFIRMED status. This is the barrier against "intelligence laundering" — promoting an unverified feed to the rank of evidence.
Evidence-first in practice. Indicator status: SIGNAL (automation) → UNDER REVIEW (analyst) → CONFIRMED (proof + signature). An unconfirmed indicator remains a signal, never presented as an operational fact.
Indicator types, their lifecycle and escalation rules. An indicator has a validity period (it does not live forever) and is retired once its intelligence value is exhausted.
| IOC type | Example | Refresh schedule | Escalation rule |
|---|---|---|---|
| IP address | reputation, C2, scanners | every 1 h (reputation feed) | hit in WAF logs → P1 |
| Domain / FQDN | phishing, C2, DGA | every 6 h | hit in outbound traffic → P1 |
| File hash (SHA-256) | malware, payload | every 12 h | hit on an endpoint → P0 |
| URL | phishing, exploit-kit, payload hosting | every 6 h | user click → P1 + phishing playbook |
| CVE | CVE-2026-XXXXX in KEV | daily (NVD) + KEV on push | presence in KEV + vulnerable asset → P0 |
The schedules above are the target pipeline configuration. Genuinely refreshed on a cycle today: KEV, NVD/CVE, GHSA, CERT advisories. IP/URL reputation feeds are in integration ROADMAP.
• CISA KEV — catalog of actively exploited vulnerabilities
• NVD / CVE — records and CVSS (JSON 2.0 feed)
• GitHub Security Advisories (GHSA)
• CERT Polska / ENISA advisories
• Own reports (CVD/intake) + WAF/CDN telemetry
• MITRE ATT&CK mapping, STIX 2.1 JSON export
• TAXII 2.1 server (collections, subscriptions)
• Bidirectional MISP sync
• SIEM connectors: Azure Sentinel, Splunk HEC, syslog RFC 5424
• Reputation feeds: AbuseIPDB, URLhaus, PhishTank (per licence)
• Vendor advisories as a structured feed
• Automatic IOC expiry after TTL
The values above describe the pipeline configuration, not the volume of a real SOC. We do not run a 24/7 analyst duty roster — CONFIRMED approval is manual and asynchronous.
Evidence layer — chain of custody, confidence level, SHA-256 hash.
Programmatic interface — export of indicators and statuses (STIX/JSON).
Handling process — KEV/CVE → triage → severity → remediation (ISO 30111).
Researcher reports — own intelligence source, safe harbor.