Wissensgraphen für militärische Aufklärung: Entitätsauflösung und Linkanalyse

Von Corvus Intelligence Engineering Team · Über das Team →

24. Juni 2026 12 Min. Lesezeit

Militärische Aufklärung war schon immer eine Frage der Verbindungen: Welcher Kommandeur führt welche Einheit, welcher Finanzier finanziert welche Zelle, welcher Infrastrukturknoten ermöglicht welche Versorgungskette. Das sind Graphprobleme. Die Daten, die diese Fragen beantworten — abgefangene Kommunikation, Agentenberichte, Metadaten von Satellitenbildern, Open-Source-Registrierungen — kommen aus einem Dutzend separater Erfassungssysteme, die dieselbe reale Entität unterschiedlich benennen und Beziehungen in inkompatiblen Formaten speichern. Wissensgraphen stellen die strukturelle Schicht bereit, die diese Fragmente zu einem kohärenten, abfragbaren Bild zusammenfügt. Dieser Artikel untersucht, wie Graphdatenbanken und Wissensgraphen in militärischen Aufklärungsworkflows eingesetzt werden — von den grundlegenden Unzulänglichkeiten relationaler Ansätze über das an PMESII ausgerichtete Ontologiedesign, die Entitätsauflösung über Multi-INT-Quellen, die STIX-Objektdarstellung, die Auswahl von Graphdatenbanken für klassifizierte Umgebungen, Cypher-Abfragemuster für die Linkanalyse bis hin zur Integration mit C2- und OSINT-Pipelines.

Warum relationale Datenbanken für Aufklärungs-Linkanalysen ungeeignet sind

Die kanonische Aufklärungsfrage lautet nicht: „Finde alle Datensätze, in denen Spalte X gleich Wert Y ist." Sie lautet: „Traversiere ausgehend von dieser Entität ihr Netzwerk bis zur Tiefe fünf, filtere nach Beziehungstyp und Konfidenz und teile mir mit, welchen Gemeinschaften diese Entitäten angehören." Relationale Datenbanken beantworten die erste Frage gut. Die zweite beantworten sie, indem sie JOIN-Operationen verketten, deren Rechenaufwand bei jedem Hop exponentiell ansteigt.

Ein zweistufiger JOIN über eine Entitätstabelle mit zehn Millionen Zeilen ist in der Regel durchführbar — vielleicht einige Sekunden mit guten Indizes. Ein fünfstufiger Self-Join über dieselbe Tabelle erfordert vier sequenzielle JOIN-Operationen, die jeweils den Arbeitsbereich um den durchschnittlichen Fan-out-Faktor vervielfachen. Bei realistischen Aufklärungsdaten — wo ein Personenknoten fünfzig Kommunikationskontakte haben kann, jeder mit fünfzig eigenen — kann der Zwischenergebnissatz bei Tiefe fünf den Arbeitsspeicher jedes Servers überschreiten, bevor überhaupt gefiltert wird. Der Abfrageoptimierer kann dies nicht vermeiden, weil die Beziehung selbst nicht als gespeichertes Objekt in der Datenbank existiert: Sie wird durch den Abgleich von Schlüsselspalten zur Abfragezeit neu berechnet. Jeder Hop ist eine vollständige Neuberechnung.

Das Problem der Entitätsdisambiguierung verschlimmert dies weiter. Eine Person erscheint in einem SIGINT-Abfang als „Ahmed M.", in einem HUMINT-Bericht als „Ahmad Mansour" und in einem Finanzdatensatz als „A. Mansouri." In einem relationalen Schema sind dies drei separate Zeilen in drei separaten Tabellen, sofern kein menschlicher Analyst (oder eine Deduplizierungspipeline) sie explizit verknüpft hat. Ohne diese Verknüpfung traversiert ein JOIN, der vom SIGINT-Datensatz ausgeht, niemals zum Finanzdatensatz, und das Netzwerk, das der Analyst sieht, ist systematisch unvollständig. Relationale Datenbanken haben keinen nativen Mechanismus, um auszudrücken: „Diese beiden Zeilen sind wahrscheinlich dieselbe Entität, mit Konfidenz 0,85." Diese Wahrscheinlichkeit muss außerhalb des Schemas in der Anwendungslogik leben, die in der Regel manuell und selten konsistent ist.

Die JOIN-Explosion und das Entitätsdisambiguierungsproblem erklären gemeinsam, warum die Linkanalyse in traditionellen Verteidigungsaufklärungssystemen — die auf relationalen Datenbanken aufgebaut sind — dedizierte Analystearbeit erforderte, die eine Graphdatenbank für die Aufklärungsanalyse automatisieren kann. Der Graph speichert Beziehungen als native Kanten mit direkten Zeigern zwischen Knoten, sodass die Traversierungskosten mit der lokalen Nachbarschaft skalieren, nicht mit der globalen Tabellengröße. Entitätsauflösung ist erstklassig: Eine Merge-Operation fasst mehrere Datensätze zu einem kanonischen Knoten zusammen, und alle Kanten, die auf einen der beiden Datensätze verwiesen haben, verweisen nun auf den kanonischen Knoten. Der Graph ist das für den Problembereich konzipierte Datenmodell.

Grundlagen von Wissensgraphen für den militärischen Einsatz

Ein Wissensgraph erweitert einen Eigenschaftsgraphen um ein gemeinsames Vokabular — eine Ontologie —, das jedem Knotentyp und Kantentyp eine definierte, vereinbarte Bedeutung verleiht. Dieses gemeinsame Vokabular ist es, was Abfragen über Quellen hinweg komponierbar macht: Zwei separate Ingestionpipelines, die beide das Knotenlabel MilitaryUnit und den Kantentyp SUBORDINATE_TO verwenden, erzeugen Graphen, die gemeinsam traversiert werden können. Ohne die Ontologie erfindet jede Pipeline ihre eigenen Namen, und der Graph akkumuliert zehn synonyme Labels für dasselbe Konzept.

Für die militärische Aufklärung liefert das PMESII-Framework ein natürliches Ontologiegerüst. Jede der sechs Dimensionen — Politisch, Militärisch, Wirtschaftlich, Sozial, Infrastruktur, Information — wird zu einer Familie von Knotenlabels:

PMESII-Dimension	Knotenlabels	Wichtige Kantentypen
Politisch	Government, Official, PoliticalParty, Faction	CONTROLS, ALLIED_WITH, OPPOSES
Militärisch	Unit, Commander, WeaponsSystem, Base	COMMANDS, SUBORDINATE_TO, EQUIPPED_WITH, DEPLOYS_AT
Wirtschaftlich	Organization, FinancialAccount, SupplyChain, Commodity	FINANCES, TRANSACTS_WITH, SUPPLIES
Sozial	Person, Group, Community	MEMBER_OF, COMMUNICATES_WITH, RECRUITS
Infrastruktur	Facility, TransportLink, PowerGrid, NetworkNode	CONNECTS, DEPENDS_ON, OPERATED_BY
Information	MediaChannel, PsyopActor, NarrativeTheme	AMPLIFIES, TARGETS, DISSEMINATES

Jeder Knoten trägt einen erforderlichen Eigenschaftssatz: eine kanonische Kennung, einen Namen, ein Klassifizierungslabel, eine Quellenreferenz und einen Erstellungszeitstempel. Jede Kante trägt: Typ, source_ref, Konfidenz (ein Float zwischen 0 und 1), valid_from (die früheste Zeit, zu der die Beziehung beobachtet wurde), valid_until (null, wenn noch aktiv) und Klassifizierung. Diese erforderlichen Eigenschaften machen den Graphen prüfbar: Jede abgeleitete Verbindung kann zu den Beobachtungen zurückverfolgt werden, die sie stützen, mit ihren Erfassungsmetadaten und Konfidenzwerten.

PMESII-übergreifende Kanten sind oft die wertvollsten Aufklärungsziele. Ein wirtschaftlicher Knoten, der einen militärischen Knoten finanziert, überquert zwei Dimensionen; ein Informationsknoten, der im Auftrag eines politischen Knotens eine Erzählung verbreitet, überquert zwei weitere. Abfragen, die speziell nach dimensionsübergreifenden Pfaden suchen — Welche Wirtschaftsorganisationen finanzieren diese Militäreinheit? — sind in einem Eigenschaftsgraphen strukturell unkompliziert, weil die Kante als natives Objekt existiert, das die beiden Knoten verbindet.

Entitätsauflösung über Multi-INT-Quellen

Aufklärungsdaten werden von Quellen erfasst, die nie dafür ausgelegt waren, eine gemeinsame Entitätskennung zu teilen. Ein SIGINT-System identifiziert eine Person anhand ihrer Telefonnummer. Ein HUMINT-Bericht nennt sie in Prosa. Ein IMINT-Analyst markiert ein Fahrzeug in einer Bildanmerkung. Eine Open-Source-Datenbank registriert eine Organisation unter ihrem rechtlichen Namen in einer fremden Schrift. All dies in einem konsistenten Graphen zusammenzuführen erfordert Entitätsauflösung: die Entscheidung, ob zwei eingehende Datensätze auf dieselbe reale Entität verweisen.

Die Auflösungspipeline hat drei Phasen. Die erste ist die Normalisierung: Bevor ein Vergleich vorgenommen werden kann, müssen Kennungen in eine kanonische Form gebracht werden. Telefonnummern werden auf das internationale E.164-Format normalisiert. Namen werden mit einem definierten Transliterationsstandard in eine gemeinsame Schrift (typischerweise Lateinisch) umgeschrieben (BGN/PCGN für slawische Sprachen, ALA-LC für Arabisch) und dann weiter auf eine Grundform normalisiert, die Höflichkeitstitel und Namensvariationen entfernt. Koordinaten werden in WGS84 umgerechnet. Ein Datensatz, dessen Telefonnummer als „0044-20-7946-0123" gespeichert ist, und ein anderer, dessen Nummer „+44 20 7946 0123" lautet, müssen beide denselben normalisierten Schlüssel erzeugen, bevor ein Blocking- oder Vergleichsschritt erfolgt.

Die zweite Phase ist das Blocking: ein Mechanismus, der begrenzt, welche Datensatzpaare verglichen werden. Den Vergleich jedes eingehenden Datensatzes mit jedem bestehenden Graphknoten durchzuführen ist quadratisch in der Komplexität und operativ bei Skalierung nicht durchführbar. Blocking-Strategien umfassen Sorted Neighborhood (Datensätze nach einem Blocking-Schlüssel sortiert, nur innerhalb eines gleitenden Fensters verglichen), Inverted-Index-Blocking (Datensätze, die mindestens ein Token in einer phonetischen Namenskodierung teilen, sind Kandidaten) und MinHash Locality-Sensitive Hashing für mengenwertige Attribute wie bekannte Aliase. Jede Strategie tauscht Recall gegen Leistung: Ein verpasster Blocking-Kandidat ist ein verpasster Entitätsabgleich, daher sollten Blocking-Schlüssel anhand eines Gold-Standard-Testsets bekannter Duplikate abgestimmt werden.

Die dritte Phase ist die Bewertung und Entscheidung. Kandidatenpaare erhalten einen Ähnlichkeitsvektor über mehrere Attribute: Namensähnlichkeit (Jaro-Winkler oder Jaccard über Namensvarianten), Identifierüberlappung (gemeinsames Telefon, IMEI, Adresse), geografische Nähe und zeitliches Zusammentreffen. Eine logistische Regression oder ein Gradient-Boosting-Klassifikator erzeugt einen Merge-Konfidenzwert. Paare oberhalb eines hohen Schwellenwerts (typischerweise 0,90) werden automatisch zusammengeführt; Paare im Unsicherheitsband (0,65–0,90) werden zur Analyse-Überprüfung in die Warteschlange gestellt; Paare unterhalb des unteren Schwellenwerts bleiben als separate Knoten.

Kritische Disziplin: Jeder Merge muss mit dem Evidenzvektor und der Konfidenz protokolliert werden, die ihn gerechtfertigt haben. Merges müssen rückgängig gemacht werden können. Ein falscher Merge — zwei verschiedene Personen, die zu einem Knoten zusammengefasst wurden — fabriziert Netzwerkverbindungen, die nicht existieren, und könnte Erfassung und Analyse gegen das falsche Ziel richten. Das Merge-Protokoll ist kein optionales Prüfungsartefakt; es ist eine Voraussetzung dafür, dass jedes Intelligence-Produkt, das der Graph unterstützt, eine Analysisüberprüfung besteht.

Die Multi-Sensor-Fusionsarchitektur, die die Spurkorrelation auf der Sensorebene übernimmt, verwendet viele der gleichen probabilistischen Prinzipien — Gating nach Position, Geschwindigkeit und Identitätsattributen — funktioniert aber mit Millisekunden-Latenz über strukturierte Sensornachrichten. Die Entitätsauflösung für Wissensgraphen operiert bei viel geringerem Volumen (Millionen von Datensätzen statt Millionen pro Sekunde), aber gegen weitaus unübersichtlichere, weniger strukturierte Daten. Beide Bereiche erfordern dieselbe Disziplin: explizite Konfidenz, reversible Entscheidungen und Prüfbarkeit.

Darstellung von STIX-Objekten in einem Graphspeicher

STIX (Structured Threat Information eXpression) ist der Standard für den Austausch von Cyber-Bedrohungsinformationen. Ein STIX-Bundle besteht aus STIX Domain Objects (SDOs) — den Entitäten: Bedrohungsakteure, Kampagnen, Indikatoren, Malware, Schwachstellen, Angriffsmuster, Infrastruktur — und STIX Relationship Objects (SROs), die gerichtete Beziehungen zwischen ihnen ausdrücken: „Bedrohungsakteur X verwendet Malware Y", „Kampagne A zielt auf Sektor B." Dies ist ein nativer Eigenschaftsgraph. Jedes SDO wird zu einem Knoten; jedes SRO wird zu einer gerichteten Kante.

Die Zuordnung ist unkompliziert:

// STIX SDO → Neo4j Node
MERGE (n:StixObject {stix_id: $bundle.id})
SET n.type        = $sdo.type,
    n.name        = $sdo.name,
    n.confidence  = $sdo.confidence,
    n.modified    = datetime($sdo.modified),
    n.revoked     = coalesce($sdo.revoked, false),
    n.labels      = $sdo.labels,
    n.classification = $sdo.object_marking_refs[0]

// STIX SRO → Neo4j Edge
MATCH (src:StixObject {stix_id: $sro.source_ref})
MATCH (tgt:StixObject {stix_id: $sro.target_ref})
MERGE (src)-[r:STIX_REL {stix_id: $sro.id}]->(tgt)
SET r.relationship_type = $sro.relationship_type,
    r.confidence        = $sro.confidence,
    r.valid_from        = datetime($sro.start_time),
    r.valid_until       = datetime($sro.stop_time),
    r.modified          = datetime($sro.modified),
    r.revoked           = coalesce($sro.revoked, false)

Zwei STIX-spezifische Komplikationen erfordern explizite Behandlung. Erstens die Versionierung: STIX aktualisiert ein Objekt, indem dieselbe ID mit einem neuen modified-Zeitstempel neu ausgegeben wird. Das oben beschriebene MERGE-on-stix_id-Muster behandelt dies korrekt, indem Eigenschaften an Ort und Stelle überschrieben werden. Für Workflows, die das Aufklärungsbild zu einem bestimmten Zeitpunkt rekonstruieren müssen — etwa bei einer Überprüfung nach einem Vorfall — ist ein temporales Versionierungsmuster erforderlich: Anstatt zu überschreiben, wird eine neue Knotenversion erstellt und Versionen mit HAS_VERSION-Kanten verkettet, wobei der Gültigkeitszeitstempel auf jedem Versionsknoten gespeichert wird.

Zweitens die Widerrufung: Ein STIX-Objekt mit revoked: true sollte von Traversierungen ausgeschlossen, aber nicht gelöscht werden, um den Prüfpfad zu erhalten. Die Konvention besteht darin, revoked: true auf dem Knoten zu setzen und jeder Traversierungsabfrage standardmäßig einen WHERE NOT n.revoked-Filter hinzuzufügen. Eine widerrufene Kante, die eine Beziehung zwischen zwei Bedrohungsakteuren behauptet hatte, muss in der Datenbank verbleiben, damit ein Analyst sehen kann, dass die Behauptung aufgestellt und später zurückgezogen wurde — der Widerruf ist selbst eine Aufklärungsinformation.

STIX definiert auch Sighting-Objekte, die aufzeichnen, dass ein SDO in einem bestimmten Kontext beobachtet wurde. Sightings werden zu Kanten, die das beobachtete Objekt mit einer beobachtenden Identität verbinden, mit sighting_count- und first/last_seen-Eigenschaften. Dies ist der Mechanismus, der abstrakte Bedrohungsinformationen — „diese Malware-Familie" — mit einer spezifischen operativen Beobachtung verknüpft: „Diese Malware wurde zu diesem Zeitpunkt in diesem Netzwerk gesehen."

Auswahl von Graphdatenbanken für militärische Umgebungen

Die Wahl einer Graphdatenbank für den klassifizierten Militäreinsatz ist in erster Linie keine Leistungsentscheidung. Mehrere nicht-funktionale Anforderungen dominieren:

Engine	Air-Gap	Abfragesprache	Native GDS-Algorithmen	Hinweise
Neo4j Enterprise	Ja (Offline-Lizenz)	Cypher / openCypher	GDS-Bibliothek: PageRank, Louvain, Dijkstra, WCC	Die meisten Analysten-Tools zielen auf Cypher; starke Akkreditierungshistorie in Five-Eyes-Deployments
TigerGraph	Ja (On-Prem-Bundle)	GSQL	Eingebaut: Zentralität, Community, Pfad	Höherer Durchsatz für Batch-Analysen; GSQL hat steilere Lernkurve für Analysten
Amazon Neptune	Nein (Cloud-Dienst)	openCypher / Gremlin / SPARQL	Neptune ML für Graph Neural Nets	Nur für TS/SCI-Cloud-Mandanten geeignet; nicht für echte Air-Gap-Umgebungen
JanusGraph	Ja (Open Source)	Gremlin	Via Spark/Hadoop-Backend	Vollständig Open Source; läuft über HBase, Cassandra oder RocksDB; am besten für Edge-Knoten mit eingebettetem Speicher

Für vorwärtsdeployierte oder netzwerkrandnahe Aufklärungsknoten — ein Exploitationsteam mit einem Laptop und einem taktischen Netzwerk — bieten eingebettete Graphspeicher auf RocksDB-Basis (JanusGraph + EmbeddedGraph) oder Neo4js Embedded-Modus den kleinsten Footprint. Für Garnisonsnetzwerke mit gleichzeitigem Multi-Analysten-Zugriff bieten das geclusterte Deployment von Neo4j Enterprise oder die verteilte Architektur von TigerGraph den erforderlichen Durchsatz für simultane Linkanalysesitzungen. Amazon Neptune ist nur dann geeignet, wenn die Klassifizierungsenklave bereits in einem souveränen Cloud-Mandanten auf dem erforderlichen Klassifizierungsniveau gehostet wird.

Eine kritische operative Überlegung ist die Multi-Level Security (MLS) Enforcement-Schicht. Die Graphdatenbank selbst ist in der Regel nicht MLS-aware: Sie speichert Daten und führt Abfragen aus, ohne inherent Klassifizierungslabels zu verstehen. Die Enforcement-Schicht sitzt im Abfrage-Gateway — einer Middleware-Komponente, die jede eingehende Cypher-Abfrage umschreibt, um eine WHERE-Klausel hinzuzufügen, die nach dem autorisierten Klassifizierungssatz des anfragenden Benutzers filtert. Dies muss sorgfältig implementiert werden: Ein auf SECRET-Ebene eingestufter Benutzer darf nicht in der Lage sein, die Existenz von TOP SECRET-Kanten durch Zeitunterschiede oder Fehlermeldungen zu erschließen, selbst wenn er den Kanteninhalt nicht sehen kann.

Abfragemuster für die Linkanalyse

Die Linkanalyse in Cypher reduziert sich auf ein kleines Vokabular von Mustern, die zu komplexen analytischen Fragen zusammengestellt werden. Die folgenden Beispiele setzen Neo4j und die GDS-Bibliothek voraus, aber die Muster lassen sich mit geringen Syntaxänderungen in GSQL oder Gremlin übersetzen.

Kürzester Pfad zwischen zwei Entitäten von Interesse:

// Kürzesten Pfad finden, gefiltert nach hochkonfidenziellen, nicht widerrufenen Kanten
MATCH (a:Entity {id: $seedA}),
      (b:Entity {id: $seedB}),
      p = shortestPath((a)-[*1..6]-(b))
WHERE ALL(r IN relationships(p)
      WHERE r.confidence >= 0.6
        AND NOT coalesce(r.revoked, false)
        AND (r.valid_until IS NULL OR r.valid_until > datetime()))
RETURN p, length(p) AS hops
ORDER BY hops ASC

K-Hop-Nachbarschaftserweiterung von einem Ausgangspunkt, mit Zeitfenster:

// 3-Hop-Nachbarschaft aktiv während eines 30-tägigen operativen Fensters
MATCH (seed:Entity {id: $seedId})-[r*1..3]-(neighbor)
WHERE ALL(rel IN r
      WHERE rel.confidence >= 0.5
        AND rel.valid_from <= $windowEnd
        AND (rel.valid_until IS NULL OR rel.valid_until >= $windowStart))
RETURN DISTINCT neighbor, labels(neighbor) AS types
LIMIT 500

Community-Erkennung mit Louvain (ausgeführt auf In-Memory-Graph-Projektion):

// Konfidenzgewichteten Teilgraphen projizieren, Louvain ausführen, Community-IDs zurückschreiben
CALL gds.graph.project(
  'intel-graph',
  ['Entity'],
  {COMMUNICATES_WITH: {properties: ['confidence']}})

CALL gds.louvain.write('intel-graph', {
  writeProperty: 'communityId',
  relationshipWeightProperty: 'confidence'
}) YIELD communityCount, modularity

// Dann die Community-Peers des Ausgangspunkts ausgeben
MATCH (seed:Entity {id: $seedId})
MATCH (peer:Entity {communityId: seed.communityId})
WHERE peer.id <> $seedId
RETURN peer ORDER BY peer.degreeCentrality DESC LIMIT 50

Temporale Linkanalyse — Aktivitätskadenz im Zeitverlauf:

// Kantenaktivierungen pro Kalenderwoche für temporale Musteranalyse zählen
MATCH (a:Entity {id: $seedId})-[r:COMMUNICATES_WITH]-()
WHERE r.valid_from >= $rangeStart AND r.valid_from <= $rangeEnd
WITH r,
     date.truncate('week', r.valid_from) AS week
RETURN week,
       count(r) AS contact_count,
       avg(r.confidence) AS avg_confidence
ORDER BY week ASC

Die temporale Linkanalyse ist die Brücke zur Verhaltensmusteranalyse im militärischen Aufklärungsbereich: Wenn die Kadenz der Kantenaktivierungen eines Knotens sich ändert — die Frequenz sinkt, die Zeiten verschieben sich, die Kontaktpartner rotieren — erkennt der Graph diese Veränderung als strukturelle Anomalie, noch bevor ein zweckgebundenes Verhaltensmodell auf der Entität trainiert wurde. Die Graphabfrage ist der Erstdetector; das Verhaltensmodell ist die Bestätigungsschicht.

Ein Hinweis zur Leistung: Community-Erkennung und Zentralitätsalgorithmen laufen über den vollständig projizierten Graphen, nicht nur einen Teilgraphen. Bei einem Graphen mit Zehnmillionen von Knoten müssen diese Algorithmen als Hintergrund-Batch-Jobs eingeplant werden, nicht als interaktive Abfragen. Die Ergebnisse — communityId und degreeCentrality, die als Knoteneigenschaften zurückgeschrieben werden — stehen dann für sofortige Nachschlagvorgänge in Analysten-Abfragen zur Verfügung, ohne den Algorithmus neu ausführen zu müssen.

Integration von Wissensgraphen mit C2- und OSINT-Pipelines

Ein Wissensgraph, der nicht mit Live-Datenquellen verbunden ist, ist ein historisches Artefakt statt eines operativen Werkzeugs. Die Integrationsarchitektur hat drei Ingestionkanäle und zwei Verbrauchsendpunkte.

CTI-Feed-Ingestion (STIX/TAXII). Ein TAXII-Client pollt registrierte Collection-Endpunkte — verbündete CTI-Sharing-Plattformen, nationale Bedrohungsinformations-Feeds — und verarbeitet eingehende STIX-Bundles durch die oben beschriebene SDO-zu-Knoten / SRO-zu-Kanten-Pipeline. Die Bundle-Verarbeitung ist idempotent: MERGE auf STIX-ID stellt sicher, dass ein erneut geliefertes Objekt Eigenschaften aktualisiert, anstatt einen doppelten Knoten zu erstellen. Neue Objekte werden gegen den bestehenden Graphen entitätsaufgelöst, bevor sie committet werden; wenn ein neuer STIX ThreatActor über probabilistische Identitätsauflösung einem bestehenden Nicht-STIX-Personenknoten entspricht, werden beide zusammengeführt, und alle Kanten beider Datensätze sind nun vom kanonischen Knoten traversierbar.

HUMINT-Berichtserfassung. Berichte aus menschlichen Quellen in natürlicher Sprache werden durch eine NLP-Pipeline verarbeitet, die Named Entity Recognition, Relationsextraktion und Korerenreferenzauflösung durchführt und dann extrahierte Entitäten und Beziehungen dem Graphschema zuordnet. Die NLP-Pipeline ist nicht der Graph: Sie ist die Transformationsschicht von Prosa zu strukturierten Graphelementen. Extrahierte Entitäten durchlaufen dieselbe Entitätsauflösungspipeline wie jede andere Quelle, mit einer typischerweise niedrigeren Basiskonfidenz (Prosaextraktion ist weniger zuverlässig als ein strukturierter Datenbankdatensatz), die auf die Kanten propagiert wird, die der HUMINT-Bericht stützt.

SIGINT-Spurerfassung. SIGINT-Beobachtungen — eine Kommunikation zwischen zwei Endpunkten zu einem bestimmten Zeitpunkt, ein Gerät an einem bestimmten Ort — kommen als Streaming-Feed an. Jede Beobachtung erstellt oder aktualisiert eine Kante im Graphen: eine COMMUNICATES_WITH-Kante zwischen zwei Personen- oder Geräteknoten oder eine OBSERVED_AT-Kante zwischen einem Gerät und einem Ort. Das valid_from der Kante ist der Beobachtungszeitstempel; valid_until ist null, sofern der SIGINT-Feed die Beobachtung nicht explizit schließt. Die hochvolumige Streaming-Ingestion erfordert einen warteschlangengestützten Ingestor (Kafka oder Äquivalent), der Beobachtungen puffert und in Batch-Schreibvorgänge im Graphen bündelt, mit einer Rate, die die Datenbank absorbieren kann, ohne interaktive Abfragen zu blockieren.

Die zwei Verbrauchsendpunkte sind die Analysten-Workstation und das C2 Common Operational Picture (COP).

Die Analysten-Workstation bietet eine Linkanalyse-Oberfläche, auf der ein Analyst eine Ausgangsentität angibt, Beziehungstypen und Konfidenzschwellen auswählt und eine begrenzte Nachbarschaft expandiert. Das Ergebnis wird als kraftgerichtetes Graphlayout gerendert, wobei Konfidenz als Kantenopazität und Community-Zugehörigkeit als Knotenfarbe kodiert sind. Zentralitätswerte bestimmen die Knotengröße. Der Analyst sieht nie den gesamten Graphen — nur den begrenzten, gefilterten, abfragegetriebenen Teilgraphen, der eine bestimmte Frage beantwortet. Eine gute Oberfläche zeigt das Cypher-Muster in einer Seitenleiste, damit der Analyst genau versteht, was abgefragt wurde, und es verfeinern kann.

Die C2-COP-Integration stellt graphabgeleitete Entitätsprofile — die bekannten Untergeordneten einer Einheit, die Community-Zugehörigkeit einer Person, die Versorgungsabhängigkeiten einer Anlage — als Popups auf dem taktischen Bild dar. Wenn der Operator auf eine verfolgte Entität klickt, fragt das C2-System den Wissensgraphen nach dem Netzwerkkontext dieser Entität ab und zeigt die fünf am engsten verwandten Entitäten nach Konfidenz und Zentralität an. Dies verwandelt den Wissensgraphen von einem eigenständigen analytischen Werkzeug in eine aktive Komponente des operativen Bildes: strukturierte Beziehungsinformationen, kontextuell verfügbar, ohne dass der Operator ein separates Tool öffnen muss.

Architekturprinzip: Der Wissensgraph ist nicht die Visualisierung — er ist die Datenschicht. Investieren Sie in Ingestionqualität, Entitätsauflösungsgenauigkeit und Index-Performance. Die Visualisierung ist die letzte Meile. Eine auf einem schlecht aufgelösten Graphen mit niedrig-konfidenziellen Kanten aufgebaute Analysten-Oberfläche wird schneller und überzeugender in die Irre führen als jeder manuelle Prozess, den sie ersetzt. Der Graph verdient operatives Vertrauen durch Prüfbarkeit: Jede angezeigte Verbindung muss auf ihre zugrunde liegenden Belege erweiterbar sein, mit angehängter Quelle, Erfassungszeit und Konfidenz.

Beziehungsinformationen in Ihr operatives Bild bringen

Corvus HEAD fusioniert Multi-Source-Aufklärung in einen abfragbaren Wissensgraphen — Entitätsauflösung, Linkanalyse und C2-integrierte Netzwerkvisualisierung, entwickelt für Analysten, die prüfbare, konfidenzgewichtete Antworten benötigen.

Corvus HEAD erkunden → Briefing buchen

Diese Analyse wurde von Corvus Intelligence-Ingenieuren erstellt, die missionskritische Aufklärungs- und Datenintegrationssysteme für Verteidigungs- und Regierungsorganisationen entwickeln. Mehr über unser Team →

Häufig gestellte Fragen

Warum machen JOIN-Explosionen relationale Datenbanken für militärische Linkanalysen ungeeignet?

Relationale Datenbanken beantworten Beziehungsfragen durch JOIN-Operationen, die den Arbeitsbereich bei jedem Hop vervielfachen. Eine zweistufige Abfrage erfordert einen Self-Join; eine fünfstufige erfordert vier, wobei jeder das vorherige Ergebnis mit einem potenziell großen Fan-out-Faktor multipliziert. Gegen eine Tabelle mit zehn Millionen Entitätsdatensätzen kann eine fünfstufige Traversierung Zwischensätze von Billionen von Zeilen erzeugen, bevor gefiltert wird. Aufklärungs-Linkanalysen benötigen routinemäßig fünf oder mehr Hops — vom abgefangenen Telefon bis zum Netzwerk der Netzwerke darüber — was relationale Tiefenabfragen entweder extrem langsam oder operativ unmöglich innerhalb einer Sitzung macht.

Was ist der Unterschied zwischen einem Eigenschaftsgraphen und einem RDF/OWL-Wissensgraphen im militärischen Kontext?

Ein Eigenschaftsgraph speichert Knoten und Kanten mit typisierten Labels und beliebigen Schlüssel-Wert-Eigenschaften auf beiden. Er ist schema-flexibel und für Traversierungsabfragen optimiert. Ein RDF-Wissensgraph modelliert alles als Subjekt-Prädikat-Objekt-Tripel; OWL fügt eine Ontologieschicht mit formaler Semantik hinzu, die Inferenz unterstützt. Für die militärische Aufklärung sind Eigenschaftsgraphen operativ praktischer: Sie verarbeiten Provenienz- und Konfidenzeigenschaften natürlich und integrieren sich mit Cypher-Tools, die Analysten bereits verwenden. RDF/OWL wird bevorzugt, wo formale Standards-Interoperabilität wichtig ist, etwa bei der Integration von STIX-Inhalten auf der semantischen Ebene oder der Verbindung mit alliierten Wissensdatenbanken über Linked-Data-Protokolle.

Wie unterscheidet sich Entitätsdisambiguierung von Entitätsauflösung im Aufklärungskontext?

Entitätsauflösung entscheidet, ob zwei strukturierte Datensätze auf dieselbe reale Entität verweisen, und führt sie zusammen. Entitätsdisambiguierung ordnet eine Texterwähnung — einen Namen in einem HUMINT-Bericht — einem bestehenden Graphknoten zu. Beide müssen der Reihe nach gelöst werden: NLP extrahiert Erwähnungen, Disambiguierung verknüpft sie mit Kandidatenknoten, und Auflösung entscheidet, ob Kandidaten dieselbe Entität sind. Fehler bei der Disambiguierung erzeugen falsche Kanten; Fehler bei der Auflösung fragmentieren oder überfusionieren Knoten. Beide erfordern Konfidenzwerte und reversible Entscheidungen mit vollständiger Protokollierung der Beweise, die jede Entscheidung geleitet haben.

Wie sieht ein STIX Relationship Object als Graphkante in neo4j aus?

Ein STIX SRO wird zu einer gerichteten Kante, deren Typ die relationship_type-Zeichenkette ist (z.B. "uses", "targets"). Die eigene STIX-ID des SRO, Konfidenz, created und modified werden als Kanteneigenschaften gespeichert. Die source_ref und target_ref lösen sich anhand ihrer stix_id-Eigenschaft in bestehende Knoten auf. Temporale Felder (valid_from, valid_until) werden als Kanteneigenschaften indiziert, damit zeitfensterbeschränkte Cypher-Abfragen Beziehungen filtern können, die während eines bestimmten operativen Fensters aktiv waren. Widerrufene SROs setzen revoked: true auf der Kante und werden durch einen Standard-WHERE-NOT-Filter von Traversierungen ausgeschlossen, bleiben aber für Prüfzwecke erhalten.

Wie werden versionierte STIX-Objekte in einem Graphspeicher behandelt?

STIX-Versionierung verwendet dieselbe ID mit einem neuen modified-Zeitstempel. Zwei Strategien sind anwendbar. Snapshot-Ersatz behält nur die neueste Version jedes Knotens — einfach, aber verliert die Geschichte. Temporale Knotenversionierung erstellt einen neuen Knoten pro modified-Zeitstempel und verkettet Versionen mit HAS_VERSION-Kanten, was Zeitreisen-Abfragen ermöglicht, um jedes vergangene Aufklärungsbild zu rekonstruieren. Für operative Aufklärung reicht Snapshot-Ersatz; für analytische Workflows, die nachverfolgen müssen, wie sich ein Bedrohungsbild vor einer Entscheidung entwickelt hat, ist temporale Versionierung unerlässlich. Beide Strategien müssen widerrufene Objekte mit revoked: true markieren und von Traversierungen unterdrücken, ohne sie zu löschen, um den Prüfpfad zu erhalten.

Was ist das Superknoten-Problem in militärischen Aufklärungsgraphen?

Ein Superknoten ist ein Knoten mit extrem hohem Grad — eine gemeinsam genutzte öffentliche Telefonleitung, eine gemeinsame NAT-IP oder ein großer Logistikknoten. Die Traversierung durch einen Superknoten multipliziert den Ergebnissatz mit seinem Grad, was Abfragen nicht terminierend macht. In der Zentralitätsanalyse erscheint der Superknoten als wichtigste Entität, obwohl er ein Infrastrukturartefakt widerspiegelt, keine operative Bedeutung. Abhilfemaßnahmen umfassen die Begrenzung der Erweiterungsdichte pro Knoten, die Pflege einer Hub-Ausschlussliste und die Anwendung gradgewichteter Kantenfilterung, sodass Kanten durch sehr hochgradige Knoten weniger zu Pfadwertungen beitragen.

Welche Graphdatenbank eignet sich am besten für Air-Gap-Militäraufklärungsdeployments?

Air-Gap-Deployments erfordern eine Graph-Engine ohne Netzwerk-Lizenzierungs-Callbacks. Neo4j Enterprise mit einer Offline-Lizenz ist die analysten-kompatible Wahl. TigerGraph unterstützt On-Premises-Paketlizenzierung. JanusGraph ist vollständig Open Source und läuft über eingebettetes RocksDB — ideal für Edge-Deployments. Amazon Neptune ist ein Cloud-Dienst und für echte Air-Gap-Umgebungen ungeeignet. Für vorwärtsdeployierte Edge-Knoten bietet JanusGraph mit RocksDB den kleinsten Footprint. Für Garnisonsnetzwerke bietet Neo4j Enterprise Clustering oder TigerGraph Distributed die benötigte Multi-Analysten-Parallelität.

Welches Cypher-Muster findet den kürzesten Aufklärungspfad zwischen zwei Entitäten?

Das kanonische Muster lautet: MATCH (a:Entity {id:$seedA}),(b:Entity {id:$seedB}), p=shortestPath((a)-[*1..6]-(b)) WHERE ALL(r IN relationships(p) WHERE r.confidence>=0.6 AND NOT r.revoked AND (r.valid_until IS NULL OR r.valid_until>datetime())) RETURN p, length(p) AS hops. Die [*1..6]-Begrenzung verhindert unkontrollierte Traversierungen. Für konfidenzgewichtete kürzeste Pfade bevorzugt das GDS-Dijkstra-Verfahren mit der Gewichtseigenschaft (1-Konfidenz) hochkonfidente Kanten, indem ihnen niedrigere Kosten zugewiesen werden.

Wie hilft Community-Erkennung Analysten bei der Priorisierung von Zielen?

Community-Erkennungsalgorithmen — Louvain, Label Propagation, schwach verbundene Komponenten — partitionieren den Graphen in Cluster von Entitäten, die intern dichter verbunden sind als extern. In der militärischen Aufklärung entspricht eine Community typischerweise einer funktionalen Zelle: Personen, die miteinander kommunizieren, ein Logistiknetzwerk, das Ressourcen teilt, oder durch Versorgungsketten verbundene Einrichtungen. Das serverseite Ausführen von Louvain und das Zurückschreiben von communityId als Knoteneigenschaft lässt Analysten sofort alle Community-Peers einer Ausgangsentität aufdecken, hochgradig-zentrale Brückenknoten zwischen ansonsten getrennten Clustern identifizieren und die Erfassung auf Community-Führungspersonen priorisieren, die durch intra-Community-Grad-Zentralität identifiziert werden.

Wie werden CTI-Feeds und Echtzeit-SIGINT-Spuren in einem Live-Wissensgraphen abgeglichen?

CTI-Feeds kommen als STIX-Bundles in Batch-Verarbeitung an; SIGINT kommt als kontinuierlicher Stream. Eine zweistufige Pipeline gleicht beide ab. Die Batch-Stufe verarbeitet STIX-Bundles: MERGE auf STIX-ID erstellt oder aktualisiert Knoten, SROs werden zu Kanten. Die Streaming-Stufe verarbeitet SIGINT-Beobachtungen durch einen Kafka-gestützten Ingestor: Jede Beobachtung wird nahezu in Echtzeit entitätsaufgelöst und erstellt eine zeitgebundene Kante. Beide Stufen schreiben in denselben Eigenschaftsgraphen, sodass Cypher-Abfragen ein einheitliches Bild sehen. Die temporalen Kanteneigenschaften des Graphen isolieren das jüngste Streaming-Fenster, ohne die Batch-Historie neu ausführen zu müssen.