CNCK0NSULTAI-Truthuni0naiHackatonipIII ↗k0nsult.dev ↗ dla botówDomeny osobne, spięte siecią CNC + kernelem.
K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / orchestrator / cti

CTI / Threat Intel Connectors — szkielet wymiany (spec / MVP)

Specyfikacja i szkielet wymiany Cyber Threat Intelligence dla ipIII: import wskaźników (IoC) i feedów oraz eksport incydentu jako STIX bundle. Docelowe standardy: MISP, OpenCTI, STIX 2.1, TAXII 2.1. To dokument projektowy — konektory są na etapie ROADMAP, a warstwa mapowania jako MVP/PoC. Nic tu nie jest oznaczone jako LIVE, dopóki nie ma dowodu (kod + test + endpoint).

Status uczciwy. Ta strona opisuje zamierzoną integrację CTI, nie działający konektor. Standardy (STIX/TAXII) i platformy (MISP/OpenCTI) są dojrzałe i publiczne — natomiast wpięcie ich do ipIII jest szkieletem na etapie ROADMAP. Wymiana danych opisana poniżej to decision support dla zespołu blue/GRC, wyłącznie na danych syntetycznych i po ustaleniu Rules of Engagement. Zgodnie z doktryną claim ≤ proof: co nie ma dowodu, jest ROADMAP, nie funkcją.
Import IoC/feed → normalizacja → incydent → export STIX bundle.

Cel: aby ipIII przyjmował wskaźniki kompromitacji z zewnętrznych źródeł CTI (feed/kolekcja TAXII, eksport MISP), znormalizował je do wewnętrznego modelu i — po zamknięciu analizy — potrafił wyeksportować incydent z powrotem jako STIX 2.1 bundle do współdzielenia z partnerami. Wszystko wyłącznie defensywnie: to wymiana wiedzy o zagrożeniach dla obrony (blue/GRC), bez elementów ataku.

PRZEPŁYW (docelowy): źródło CTI (MISP / TAXII feed)import IoCnormalizacjaincydent ipIIIevidence-packageexport STIX bundle

Zakres i standardy

MISP ROADMAP

Malware Information Sharing Platform. Import atrybutów/eventów (IoC) oraz publikacja obserwacji. Wymiana przez PyMISP / REST API lub feed w formacie MISP JSON. Docelowo mapowanie MISP event → incydent ipIII.

OpenCTI ROADMAP

Platforma korelacji CTI oparta o model STIX. Wymiana przez GraphQL API / konektory STIX. Docelowo: pobranie obiektów (indicator, malware, threat-actor) i wzbogacenie kontekstu incydentu.

STIX 2.1 MVP mapping

Structured Threat Information Expression. Format serializacji obiektów CTI (indicator, observed-data, relationship). Warstwa mapowania incydent ↔ STIX jako PoC — patrz przykład bundle poniżej.

TAXII 2.1 ROADMAP

Trusted Automated eXchange of Intelligence Information. Protokół transportu STIX (API Root, Collections, poll/push). Docelowo klient TAXII do subskrypcji kolekcji i publikacji własnych obserwacji.

Kierunki wymiany

KierunekCoStandard / kanałZastosowanieStatus
Import (in) IoC: adresy IP, domeny, hashe plików, URL; feed / kolekcja MISP JSON / TAXII 2.1 poll / STIX 2.1 bundle Wzbogacenie incydentu o kontekst zagrożenia, korelacja findingów z wskaźnikami ROADMAP
Export (out) Incydent ipIII jako STIX bundle (indicator + observed-data + relationship) STIX 2.1 bundle / TAXII 2.1 push Współdzielenie obserwacji z partnerami / sektorowym CSIRT (po RoE) MVP mapping / PoC
Normalizacja Mapowanie pól źródłowych → wewnętrzny model IoC ipIII schemat wewnętrzny + walidacja Jednolity model niezależnie od źródła (MISP vs OpenCTI vs surowy STIX) ROADMAP

Legenda: ROADMAP = zaplanowane, brak działającego konektora · MVP mapping / PoC = szkielet mapowania na danych syntetycznych, bez integracji produkcyjnej.

Przykład: syntetyczny STIX 2.1 bundle (export incydentu)

Poniżej syntetyczny przykład tego, jak incydent ipIII mógłby zostać wyeksportowany jako STIX 2.1 bundle. Wartości (IP, hash, id) są zmyślone i służą wyłącznie ilustracji struktury. To nie są realne wskaźniki i nie opisują żadnego rzeczywistego zdarzenia.

{
  "type": "bundle",
  "id": "bundle--00000000-0000-4000-8000-000000000001",
  "objects": [
    {
      "type": "identity",
      "spec_version": "2.1",
      "id": "identity--00000000-0000-4000-8000-0000000000a1",
      "created": "2026-07-05T00:00:00.000Z",
      "modified": "2026-07-05T00:00:00.000Z",
      "name": "K0NSULT ipIII (syntetyczny nadawca)",
      "identity_class": "organization"
    },
    {
      "type": "indicator",
      "spec_version": "2.1",
      "id": "indicator--00000000-0000-4000-8000-0000000000b2",
      "created": "2026-07-05T00:00:00.000Z",
      "modified": "2026-07-05T00:00:00.000Z",
      "name": "Syntetyczny IoC: adres C2 (przyklad)",
      "description": "Dane syntetyczne — wylacznie ilustracja struktury STIX.",
      "indicator_types": ["malicious-activity"],
      "pattern": "[ipv4-addr:value = '203.0.113.10']",
      "pattern_type": "stix",
      "valid_from": "2026-07-05T00:00:00.000Z"
    },
    {
      "type": "observed-data",
      "spec_version": "2.1",
      "id": "observed-data--00000000-0000-4000-8000-0000000000c3",
      "created": "2026-07-05T00:00:00.000Z",
      "modified": "2026-07-05T00:00:00.000Z",
      "first_observed": "2026-07-05T00:00:00.000Z",
      "last_observed": "2026-07-05T00:00:00.000Z",
      "number_observed": 1,
      "object_refs": ["file--00000000-0000-4000-8000-0000000000d4"]
    },
    {
      "type": "file",
      "spec_version": "2.1",
      "id": "file--00000000-0000-4000-8000-0000000000d4",
      "hashes": {
        "SHA-256": "0000000000000000000000000000000000000000000000000000000000000000"
      },
      "name": "sample-artifact.bin (syntetyczny)"
    },
    {
      "type": "relationship",
      "spec_version": "2.1",
      "id": "relationship--00000000-0000-4000-8000-0000000000e5",
      "created": "2026-07-05T00:00:00.000Z",
      "modified": "2026-07-05T00:00:00.000Z",
      "relationship_type": "based-on",
      "source_ref": "indicator--00000000-0000-4000-8000-0000000000b2",
      "target_ref": "observed-data--00000000-0000-4000-8000-0000000000c3"
    }
  ]
}
Dlaczego bundle, a nie payload. Eksport dotyczy wiedzy o zagrożeniu (wskaźniki, obserwacje, relacje), a nie kodu ataku. Zgodnie z zasadą defensywną ipIII nie generuje ani nie dystrybuuje payloadów, exploitów ani instrukcji ataku — STIX bundle opisuje co zaobserwowano, żeby obrońca mógł wykryć i zablokować.

Import IoC / feed — model docelowy

1. Źródło. Kolekcja TAXII 2.1, feed MISP JSON lub ręczny upload STIX 2.1 bundle. Uwierzytelnianie i zakres per źródło.
2. Import. Pobranie obiektów (indicator, observed-data, file, relationship) i walidacja względem schematu STIX 2.1.
3. Normalizacja. Mapowanie do wewnętrznego modelu IoC ipIII (typ, wartość, źródło, ważność, TLP).
4. Korelacja. Dopasowanie do istniejących findingów / incydentów jako wsparcie decyzji analityka.
5. Export. Po zamknięciu analizy — złożenie incydentu z powrotem w STIX bundle do współdzielenia (po RoE).

Wszystkie kroki na etapie ROADMAP; dziś istnieje jedynie szkielet mapowania (przykład powyżej) jako PoC.

Architektura referencyjna węzła CTI (spec, ROADMAP)

Poniżej architektura referencyjna zaprojektowana dla federacyjnego węzła CTI ipIII — dokument projektowy z fali IP3-W6-R5-T04, nieuruchomiony. Pokazuje docelowy przepływ i minimalny stos technologiczny, nie działający system.

[MISP]
  |  REST / PyMISP
  v
[CTI Normalizer]
  |  STIX 2.1 bundles
  v
[TAXII Server] <----> [Federacja / partnerzy]
  |
  v
[OpenCTI Connector]
  |
  v
[OpenCTI Platform]

MISP ROADMAP

Źródło zdarzeń, atrybutów i korelacji operacyjnej.

STIX 2.1 MVP mapping

Kanon danych — format wymiany między wszystkimi elementami stosu.

TAXII 2.1 ROADMAP

Interfejs federacyjny — transport kolekcji STIX między partnerami.

OpenCTI ROADMAP

Graf wiedzy i analityka — model grafowy relacji CTI.

Elementy pomocnicze w projekcie: PostgreSQL (storage OpenCTI), Elastic (indeksacja), Redis/RabbitMQ (kolejka importu, etap 2). Żaden z elementów tego stosu nie jest dziś uruchomiony w ipIII — to specyfikacja docelowa, nie inwentarz działającej infrastruktury.

Mapowanie pól MISP → STIX 2.1 (spec projektowa)

Tabela mapowania pól źródłowych MISP na obiekty STIX 2.1 jako podstawa przyszłego normalizera. Status ROADMAP — mapowanie opisane w dokumencie projektowym, konektor niewdrożony.

MISPSTIX 2.1
EventReport / Grouping
Attribute ip-srcIPv4Address / IPv6Address
Attribute domainDomainName
Attribute urlURL observable
Attribute md5/sha256File observable + hashes
Galaxy Threat ActorIntrusion Set / Threat Actor
Galaxy MalwareMalware
Tag TLPMarkingDefinition
Object relationshipRelationship
Dlaczego wymagany jest normalizer. Claim: własny normalizer jest potrzebny. Proof: eksport STIX z MISP zwykle zachowuje semantykę MISP, ale nie zawsze tworzy relacje i typy oczekiwane przez OpenCTI (threat actor, intrusion set, malware, campaign) — bez warstwy normalizacji mapowanie pozostaje niepełne.

Przykład pipeline'u importu (spec kodu, nieuruchomiony)

Poniższy fragment Pythona to przykład projektowy z dokumentu specyfikacji — ilustruje zamierzony kształt normalizera MISP→STIX. Kod nie jest uruchomiony w ipIII, nie ma testu integracyjnego ani endpointu; status ROADMAP.

from pymisp import PyMISP
from stix2 import Indicator, Bundle
from datetime import datetime, timezone

misp = PyMISP(url="https://misp.local", key="MISP_API_KEY", ssl=True)
events = misp.search(controller="events", timestamp="24h", pythonify=True)

objects = []
for event in events:
    for attr in event.attributes:
        if attr.type == "domain":
            indicator = Indicator(
                name=f"MISP domain {attr.value}",
                pattern=f"[domain-name:value = '{attr.value}']",
                pattern_type="stix",
                valid_from=datetime.now(timezone.utc)
            )
            objects.append(indicator)

bundle = Bundle(objects)
print(bundle.serialize(pretty=True))

TAXII 2.1 — kolekcje i uprawnienia (spec)

Rekomendacja projektowa: osobne kolekcje per TLP lub domena operacyjna, token per partner, immutable append dla bundle, deduplikacja po id i modified. Status ROADMAP — brak wdrożonego serwera TAXII w ipIII.

/api/taxii2/
  discovery
  collections/
    tlp-clear/
    tlp-amber/
    malware/
    phishing/
RolaDostęp
federation-readerGET collections, GET objects
federation-publisherPOST objects
federation-adminmanage collections

Reguły TLP i deduplikacja (spec)

TLP:CLEAR

Federacja publiczna — eksport dozwolony wg projektu.

TLP:GREEN

Społeczność zaufana — eksport dozwolony w obrębie grupy.

TLP:AMBER

Konkretni odbiorcy — eksport ograniczony do wskazanych partnerów.

TLP:RED nie eksportować

Nie eksportować automatycznie — wymaga ręcznej decyzji analityka.

Filtr eksportu (przykład projektowy, nieuruchomiony):

def export_allowed(tags):
    if "tlp:red" in [t.lower() for t in tags]:
        return False
    return True

Deduplikacja: klucz stix_id + modified; dla IoC bez stabilnego STIX ID — sha256(type + value + source + first_seen). Oba warianty to specyfikacja, nie działający kod.

Walidacja i testy akceptacyjne (spec — nieuruchomione)

Warunki akceptacji zaprojektowane dla przyszłego pipeline'u — dziś bez działającego harnessu w ipIII. Status ROADMAP.

Test 1 — MISP → STIX. Export + walidacja schematu (stix2_validator bundle.json). Sukces: walidator OK, bundle zawiera obiekty indicator/domain/file.
Test 2 — STIX → TAXII. POST bundle do kolekcji TAXII z tokenem Bearer. Sukces: HTTP 202/200.
Test 3 — TAXII → OpenCTI. Weryfikacja w OpenCTI (Indicators / Observables / Reports). Sukces: indicator i observable obecne, relacja z raportem i marking TLP zachowane.

Wymogi bezpieczeństwa pipeline'u (spec)

Bez eksportu (zasada projektowa): danych osobowych, wewnętrznych komentarzy analityków, źródeł HUMINT, tagów operacyjnych, atrybutów o ograniczonej dystrybucji wg polityki źródła.

Etapy wdrożenia (ROADMAP)

EtapZakresStatus
Etap 1MISP REST export, normalizer Python, walidator STIX 2.1, serwer TAXII 2.1, konektor importu OpenCTIROADMAP
Etap 2kolejka Redis/RabbitMQ, retry nieudanych importów, metryki Prometheus, audit log, deduplikacja globalnaROADMAP
Etap 3dwukierunkowa federacja, confidence scoring, source reliability, automatyczne wygaszanie IoC, konektory wzbogacaniaROADMAP

Podsumowanie statusu

4
Standardy w zakresie
MISP · OpenCTI · STIX 2.1 · TAXII 2.1
1
MVP mapping / PoC
export incydent → STIX bundle (syntetyczny)
0
Konektory LIVE
import/export produkcyjny = ROADMAP
100%
Dane syntetyczne
zero realnych IoC na tej stronie
Granica etyczna i prawna. CTI w ipIII służy wyłącznie obronie i zgodności (GRC/blue): wymiana wiedzy o zagrożeniach, wykrywanie i blokowanie. Bez payloadów, exploitacji i hack-back. Wszystkie przykłady są syntetyczne; jakiekolwiek działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement. Mapowania obowiązków / terminów to decision support, nie porada prawna.

Powiązane: rejestr konektorów → /connectors · warstwa threat intel → /threat-intel · znane ograniczenia (uczciwie) → /known-limitations.