Tietograafit sotilastiedustelussa: entiteettien ratkaisu ja linkkianalyysi

Kirjoittanut Corvus Intelligence Engineering Team · Tietoa tiimistä →

24. kesäkuuta 2026 12 min lukuaika

Sotilastiedustelu on aina ollut yhteyksien tunnistamista: mikä komentaja johtaa mitäkin yksikköä, mikä rahoittaja tukee mitäkin solua, mikä infrastruktuurisolmu mahdollistaa minkäkin logistiikkaketjun. Nämä ovat graafiongelpia. Data, joka vastaa näihin kysymyksiin — kaapatut viestinnät, agenttiraportit, satelliittikuvien metadata, avoimen lähteiden rekisteröinnit — saapuu tusinasta erillisestä keräysjärjestelmästä, joista jokainen nimeää saman todellisen maailman entiteetin eri tavalla ja tallentaa suhteet yhteensopimattomiin muotoihin. Tietograafit tarjoavat rakenteellisen kerroksen, joka yhdistää nämä palaset yhtenäiseksi, kyseltäväksi kuvaksi. Tässä artikkelissa tarkastellaan, miten graafiTietokantoja ja tietograafeja sovelletaan sotilastiedustelutyövirroissa — relaatiolähestymistapojen perustavanlaatuisista puutteista PMESII:hin kohdistetun ontologian suunnittelun, multi-INT-lähteiden entiteettien ratkaisun, STIX-objektien esityksen, graafiTietokannan valinnan luokiteltuihin ympäristöihin, Cypher-kyselykaavioiden linkkianalyysiin ja integraation C2- sekä OSINT-putkistoihin kautta.

Miksi relaatiotietokannat epäonnistuvat tiedustelulinkkianalyysissä

Kanoninen tiedustelukysymys ei ole "löydä kaikki tietueet, joissa sarake X on yhtä suuri kuin arvo Y." Se on "aloita tästä entiteetistä, traversoi sen verkko viiteen syvyyteen, suodata suhdetyypin ja luottamuksen mukaan ja kerro minulle, mihin yhteisöihin nämä entiteetit kuuluvat." Relaatiotietokannat vastaavat ensimmäiseen kysymykseen hyvin. Ne vastaavat toiseen ketjuttamalla JOIN-operaatioita, joiden laskennalliset kustannukset kasvavat jokaisella hypyllä.

Kahden hypyn JOIN kymmenen miljoonan rivin entiteettitaulun yli on yleensä hallittavissa, ehkä muutama sekunti hyvällä indeksoinnilla. Viiden hypyn itse-JOIN saman taulukon yli vaatii neljä peräkkäistä JOIN-operaatiota, joista jokainen kertoo työsarjan keskimääräisellä laajentumistekijällä. Realistista tiedusteludataa vastaan — jossa henkilösolmulla saattaa olla viisikymmentä viestintäkontaktia, joista jokaisella on omia viisikymmentä — välivaiheen tulosjoukko syvyydellä viisi voi ylittää minkä tahansa palvelimen muistin ennen kuin suodatusta edes sovelletaan. Kyselyoptimoija ei voi välttää tätä, koska suhde itse ei ole olemassa tietokannassa tallennettuna objektina: se lasketaan uudelleen avaimsarakkeita yhdistelemällä kyselyhetkellä. Jokainen hyppy on täydellinen uudelleenlaskenta.

Entiteettien yksiselitteistämisongelma pahentaa tätä entisestään. Henkilö esiintyy SIGINT-sieppauksessa nimellä "Ahmed M." ja HUMINT-raportissa nimellä "Ahmad Mansour" ja taloushallintotietueessa nimellä "A. Mansouri." Relaatioskeemassa nämä ovat kolme erillistä riviä kolmessa erillisessä taulussa, ellei ihmisanalyytikko (tai deduplikointiputkisto) ole nimenomaisesti linkittänyt niitä. Ilman tätä linkkiä SIGINT-tietueesta alkava JOIN ei koskaan kulje taloustietueeseen, ja analyytikon näkemä verkko on systemaattisesti epätäydellinen. Relaatiotietokannoilla ei ole natiivimekanismia ilmaista "nämä kaksi riviä ovat todennäköisesti sama entiteetti, luottamusarvolla 0,85." Tämä todennäköisyys täytyy elää skeeman ulkopuolella, sovelluslogiikassa, joka on yleensä manuaalinen ja harvoin johdonmukainen.

JOIN-räjähdys ja entiteettien yksiselitteistämisongelma yhdessä selittävät, miksi linkkianalyysi perinteisissä puolustustiedustelujärjestelmissä — jotka on rakennettu relaatiotietokantoihin — vaati omistettua analyytikkotyötä, jonka tiedusteluanalyysin graafiTietokanta voi automatisoida. Graafi tallentaa suhteet natiivikaarina, joissa on suorat osoittimet solmujen välillä, joten traversoinnin kustannus skaalautuu paikallisen naapuruston mukaan, ei globaalin taulukon koon mukaan. Entiteettien ratkaisu on ensiluokkainen: yhdistämisoperaatio tiivistää useita tietueita yhdeksi kanoniseksi solmuksi, ja kaikki kaaret, jotka viittasivat kumpaankin tietueeseen, viittaavat nyt kanoniseen solmuun. Graafi on tietomalli, joka on suunniteltu ongelma-alueelle.

Tietograafien perusteet sotilaskäyttöön

Tietograafi laajentaa ominaisuusgraafin jaetulla sanastolla — ontologialla — joka antaa jokaiselle solmutyypille ja kaaritype merkityksen, joka on määritelty ja sovittu. Tämä jaettu sanasto tekee kyselyistä yhdistettäviä eri lähteissä: kaksi erillistä ingestointiputkistoa, jotka molemmat käyttävät solmumerkintää MilitaryUnit ja kaariotyyppiä SUBORDINATE_TO, tuottavat graafeja, jotka voidaan traversoida yhdessä. Ilman ontologiaa jokainen putkisto keksii omat nimensä, ja graafi kerääntyy kymmenen synonyymistä merkintää samalle käsitteelle.

Sotilastiedustelussa PMESII-viitekehys tarjoaa luontevan ontologialuonnan. Jokainen kuudesta ulottuvuudesta — Poliittinen, Sotilaallinen, Taloudellinen, Sosiaalinen, Infrastruktuuri, Informaatio — muodostaa perheen solmumerkintöjä:

PMESII-ulottuvuus	Solmumerkinnät	Tärkeimmät kaariTypes
Poliittinen	Government, Official, PoliticalParty, Faction	CONTROLS, ALLIED_WITH, OPPOSES
Sotilaallinen	Unit, Commander, WeaponsSystem, Base	COMMANDS, SUBORDINATE_TO, EQUIPPED_WITH, DEPLOYS_AT
Taloudellinen	Organization, FinancialAccount, SupplyChain, Commodity	FINANCES, TRANSACTS_WITH, SUPPLIES
Sosiaalinen	Person, Group, Community	MEMBER_OF, COMMUNICATES_WITH, RECRUITS
Infrastruktuuri	Facility, TransportLink, PowerGrid, NetworkNode	CONNECTS, DEPENDS_ON, OPERATED_BY
Informaatio	MediaChannel, PsyopActor, NarrativeTheme	AMPLIFIES, TARGETS, DISSEMINATES

Jokaisella solmulla on pakollinen ominaisuusjoukko: kanoninen tunniste, nimi, luokitusmerkintä, lähdeviite ja luomisaikaleima. Jokaisella kaarella on: tyyppi, source_ref, luottamus (liukuluku välillä 0 ja 1), valid_from (aikaisin havaitsemisaika), valid_until (null jos edelleen aktiivinen) ja luokitus. Nämä pakolliset ominaisuudet tekevät graafista auditoitavan: mikä tahansa johdettu yhteys voidaan jäljittää sitä tukeviin havaintoihin, keräysmetadatoineen ja luottamuspisteineen.

PMESII-ulottuvuuksien väliset kaaret ovat usein arvokkaimpia tiedustelukohteita. Taloudellinen solmu, joka rahoittaa Sotilaallista solmua, ylittää kaksi ulottuvuutta; Informaatiosolmu, joka levittää narratiivia Poliittisen solmun puolesta, ylittää kaksi muuta. Kyselyt, jotka nimenomaisesti etsivät ulottuvuuksien välisiä polkuja — mitkä taloudelliset organisaatiot rahoittavat tätä sotilasyksikköä? — ovat rakenteellisesti suoraviivaisia ominaisuusgraafissa, koska kaari on natiiviobjekti, joka yhdistää kaksi solmua.

Entiteettien ratkaisu multi-INT-lähteissä

Tiedusteludata kerätään lähteistä, joita ei koskaan ole suunniteltu jakamaan yhteistä entiteettitunnistetta. SIGINT-järjestelmä tunnistaa henkilön puhelinnumeron perusteella. HUMINT-raportti nimeää heidät proosassa. IMINT-analyytikko merkitsee ajoneuvon kuvamerkinnässä. Avoimen lähteiden tietokanta rekisteröi organisaation sen juridisella nimellä vieraassa kirjoitusjärjestelmässä. Kaikkien näiden saaminen yhtenäiseen graafiin vaatii entiteettien ratkaisua: päättäminen, jokaisen saapuvan tietueparin osalta, viittaavatko ne samaan todellisen maailman entiteettiin.

Ratkaisuputkistossa on kolme vaihetta. Ensimmäinen on normalisointi: ennen kuin mitään vertailua voidaan tehdä, tunnisteet on saatettava kanoniseen muotoon. Puhelinnumerot normalisoidaan kansainväliseen E.164-muotoon. Nimet translitteroidaan yhteiseen kirjoitusjärjestelmään (tyypillisesti latinalaiseen) käyttäen määriteltyä translitteraatiostandardia (BGN/PCGN slaavilaisille kielille, ALA-LC arabialle) ja normalisoidaan sitten perusmuotoon, joka poistaa kohteliaisuuslisäkkeet ja nimivariaatiot. Koordinaatit muunnetaan WGS84:ään. Tietue, jonka puhelinnumero on tallennettuna muodossa "0044-20-7946-0123" ja toinen, jonka numero on "+44 20 7946 0123", täytyy molempien tuottaa sama normalisoitu avain ennen mitään lohkotus- tai vertailuvaihetta.

Toinen vaihe on lohkotus: mekanismi, joka rajoittaa, mitä tietuepareja vertaillaan. Jokaisen saapuvan tietueen vertaaminen kaikkiin olemassa oleviin grafisolmuihin on neliöllinen monimutkaisuudeltaan ja operatiivisesti mahdoton skaalassa. Lohkotusstrategioita ovat lajiteltu naapurusto (tietueet lajitellaan lohkotusavaimen mukaan ja vertaillaan vain liukuvan ikkunan sisällä), käänteishakemistolohkotus (tietueet, jotka jakavat vähintään yhden tokenin foneettisessa nimen koodauksessa, ovat ehdokkaita) ja MinHash-paikallistuntohashing joukkoarvoattribuuteille kuten tunnetuille aliaksille. Jokainen strategia kauppaa palautuskyvyn suorituskykyä: puuttuva lohkotusehdokas on puuttuva entiteettimatch, joten lohkotusavaimet tulisi virittää tunnettujen duplikaattien kultastandardin testijoukkoa vastaan.

Kolmas vaihe on pisteytys ja päätös. Ehdokaparit saavat samanlaisuusvektorin useiden attribuuttien yli: nimen samanlaisuus (Jaro-Winkler tai Jaccard nimitokenien yli), tunnisteen päällekkäisyys (jaettu puhelin, IMEI, osoite), maantieteellinen läheisyys ja ajallinen yhteisesiintyminen. Logistinen regressio tai gradienttivahvistettu luokitin tuottaa yhdistämisen luottamuspistemäärän. Korkean kynnyksen ylittävät parit (tyypillisesti 0,90) yhdistetään automaattisesti; epävarmuusvyöhykkeessä olevat parit (0,65–0,90) asetetaan jonoon analyytikkoarviointia varten; alemman kynnyksen alittavat parit jätetään erillisiksi solmuiksi.

Kriittinen kurinalaisuus: Jokainen yhdistäminen on kirjattava todistevektorin ja sen perustelujen luottamuksen kanssa. Yhdistämisten on oltava peruutettavissa. Virheellinen yhdistäminen — kaksi eri henkilöä tiivistettynä yhdeksi solmuksi — luo verkkoyhteyksiä, joita ei ole olemassa, ja saattaa ohjata keräyksen ja analyysin väärään kohteeseen. Yhdistämisloki ei ole mukava auditoinnin apuväline; se on edellytys sille, että mikä tahansa graafin tukema tiedustelutuote selviää analyyttisesta arvioinnista.

Multi-sensori-fuusioarkkitehtuuri, joka käsittelee raidan korrelaatiota anturitasolla, käyttää monia samoja todennäköisyysperiaatteita — porttaus sijainnin, nopeuden ja identiteettiattribuuttien perusteella — mutta toimii millisekunnin latensilla strukturoitujen anturiviestien yli. Tietograafien entiteettien ratkaisu toimii paljon pienemmällä volyymilla (miljoonat tietueet miljoonien sijaan sekunnissa) mutta paljon sotkuisempaa, vähemmän strukturoitua dataa vastaan. Molemmilla alueilla vaaditaan sama kurinalaisuus: eksplisiittinen luottamus, peruutettavat päätökset ja auditoitavuus.

STIX-objektien esittäminen graafivarastossa

STIX (Structured Threat Information eXpression) on standardistandardi kyberuhkatiedusteluun jakamiseen. STIX-paketti koostuu STIX-verkkotunnusobjekteista (SDO) — entiteeteistä: uhkatoimijat, kampanjat, indikaattorit, haittaohjelmat, haavoittuvuudet, hyökkäyskaaviot, infrastruktuuri — ja STIX-suheobjekteista (SRO), jotka ilmaisevat suunnattuja suhteita niiden välillä: "UhkaToimija X käyttää Haittaohjelmaa Y," "Kampanja A kohdistuu Sektoriin B." Tämä on natiivi ominaisuusgraafi. Jokainen SDO muuttuu solmuksi; jokainen SRO muuttuu suunnatuksi kaareksi.

Yhdistäminen on suoraviivainen:

// 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)

Kaksi STIX-kohtaista mutkikkuutta vaatii eksplisiittisen käsittelyn. Ensinnäkin, versiointi: STIX päivittää objektin uudelleenjulkaisemalla saman tunnuksen uudella muokatulla aikaleimalla. Yllä oleva MERGE-on-stix_id-kaavio käsittelee tämän oikein korvaamalla ominaisuudet paikan päällä. Työnkuluille, joiden täytyy rekonstruoida tiedustelukuva tietyllä hetkellä — kuten tapauksen jälkeinen tarkastelu — tarvitaan ajallinen versiointikaavio: korvaamisen sijaan luodaan uusi solmuversio ja versiot ketjutetaan HAS_VERSION-kaarilla, joissa jokaiseen versiosolmuun tallennetaan voimassaoloaikaleima.

Toiseksi, peruuttaminen: STIX-objekti, jossa revoked: true, tulisi sulkea pois traversoinneista mutta ei poistaa, jotta auditoinnin jälki säilyy. Käytäntönä on asettaa revoked: true solmulle ja lisätä WHERE NOT n.revoked -suodatin jokaiseen traversointikyselyyn oletuksena. Peruutettu kaari, joka väitti suhdetta kahden uhkatoimijan välillä, täytyy säilyä tietokannassa, jotta analyytikko voi nähdä, että väite tehtiin ja myöhemmin peruutettiin — peruuttaminen itsessään on tiedustelutietoa.

STIX määrittelee myös Sighting-objekteja, jotka kirjaavat, että SDO havaittiin tietyssä kontekstissa. Sightingit yhdistyvät kaariin, jotka yhdistävät havaitun objektin havainnoivaan identiteettiin, sighting_count- ja first/last_seen-ominaisuuksien kanssa. Tämä on mekanismi, joka yhdistää abstraktin uhkatiedon — "tämä haittaohjelmarikollisuusperhe" — tiettyyn operatiiviseen havaintoon: "tämä haittaohjelma nähtiin tässä verkossa tähän aikaan."

GraafiTietokannan valinta sotilasympäristöihin

GraafiTietokannan valinta luokiteltuun sotilaskäyttöön ei ole ensisijaisesti suorituskykypäätös. Useat ei-toiminnalliset rajoitteet hallitsevat:

Moottori	Ilmarakoinen	Kyselykieli	Natiivilähde-algoritmit	Huomautukset
Neo4j Enterprise	Kyllä (offline-lisenssi)	Cypher / openCypher	GDS-kirjasto: PageRank, Louvain, Dijkstra, WCC	Suurin osa analyytikkotyökaluista kohdistuu Cypheriin; vahva akkreditointihistoria Five Eyes -käyttöönotoissa
TigerGraph	Kyllä (on-prem-paketti)	GSQL	Sisäänrakennettu: keskeisyys, yhteisö, polku	Korkeampi läpäisykyky eräanalytiikalle; GSQL:n jyrkempi oppimiskäyrä analyytikoille
Amazon Neptune	Ei (pilvipalvelu)	openCypher / Gremlin / SPARQL	Neptune ML graafineuraaliverkoille	Sopii vain TS/SCI-pilvitenansseille; ei todelliseen ilmarakoympäristöön
JanusGraph	Kyllä (avoimen lähdekoodin)	Gremlin	Spark/Hadoop-taustan kautta	Täysin avoimen lähdekoodin; toimii HBase-, Cassandra- tai RocksDB-taustojen yli; paras reunakäyttöön sisäänrakennetulla tallennuksella

Eteentyönnettyihin tai verkon reunalle sijoitettuihin tiedustelusolmuihin — hyödyntämistiimi kannettavan tietokoneen ja taktisen verkon kanssa — RocksDB:n (JanusGraph + EmbeddedGraph) tai Neo4j:n upotetun tilan tukema graafimyymälät tarjoavat pienimmän jalanjäljen. Varuskunta-analyyttisille verkoille, joissa on useita samanaikaisia analyytikkoja, Neo4j Enterprisen klusteroitu käyttöönotto tai TigerGraphin hajautettu arkkitehtuuri tarjoavat tarvittavan läpäisykyvyn samanaikaisiin linkkianalyysiistuntoihin. Amazon Neptune sopii vain silloin, kun luokitusklavi on jo isännöity suvereenissa pilvitenansissa vaaditulla luokitustasolla.

Kriittinen operatiivinen näkökohta on moniluokkaisen turvallisuuden (MLS) valvontakerros. GraafiTietokanta itsessään ei yleensä ole MLS-tietoinen: se tallentaa tietoja ja suorittaa kyselyjä ymmärtämättä luokitusmerkintöjä luonnostaan. Valvontakerros sijaitsee kyselygatewayssa — väliohjelmistokomponentissa, joka kirjoittaa jokaisen saapuvan Cypher-kyselyn uudelleen lisäämällä WHERE-lausekkeen, joka suodattaa pyytävän käyttäjän valtuutetun luokitusjoukon mukaan. Tämä on toteutettava huolellisesti: SECRET-tasolle vapautettu käyttäjä ei saa pystyä päättelemään TOP SECRET -kaarien olemassaoloa ajoituserojen tai virheilmoitusten kautta, vaikka he eivät näkisi kaaren sisältöä.

Kyselykaaviot linkkianalyysiä varten

Linkkianalyysi Cypherissä pelkistyy pieneksi joukoksi kaavioita, jotka yhdistyvät monimutkaisiksi analyyttisiksi kysymyksiksi. Seuraavat esimerkit olettavat Neo4j:n ja GDS-kirjaston, mutta kaaviot kääntyvät GSQL:ään tai Gremliniin pienillä syntaksimuutoksilla.

Lyhin polku kahden kiinnostavan entiteetin välillä:

// Lyhin polku, suodata korkean luottamuksen, ei-peruutettuihin kaariin
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-hypyn naapuruston laajennus siemenestä, aikaikkunalla:

// 3-hypyn naapurusto aktiivisena 30 päivän operatiivisella ikkunalla
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

Yhteisön tunnistus Louvainilla (ajetaan muistingraafiprojektiossa):

// Projisoi luottamuksella painotettu aligraafi, aja Louvain, kirjoita yhteisötunnisteet takaisin
CALL gds.graph.project(
  'intel-graph',
  ['Entity'],
  {COMMUNICATES_WITH: {properties: ['confidence']}})

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

// Hae sitten siemenen yhteisön vertaissolmut
MATCH (seed:Entity {id: $seedId})
MATCH (peer:Entity {communityId: seed.communityId})
WHERE peer.id <> $seedId
RETURN peer ORDER BY peer.degreeCentrality DESC LIMIT 50

Ajallinen linkkianalyysi — toimintarytmi ajan kuluessa:

// Laske kaaren aktivaatiot kalenteriviikolla ajallista kaavaanalyysiä varten
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

Ajallinen linkkianalyysi on silta sotilaskohtaisten elämäntapamallianalyysin käytäntöihin: kun solmun kaarien aktivaatioiden rytmi muuttuu — taajuus laskee, tunnit vaihtuvat, kontaktipartnerit vaihtuvat — graafi paljastaa tämän muutoksen rakenteellisena poikkeavuutena, vaikka tarkoitukseen rakennettua käyttäytymismallia ei vielä olisi koulutettu entiteetille. Graafidkysely on ensimmäisen kierroksen ilmaisin; käyttäytymismalli on vahvistava kerros.

Huomio suorituskykyyn: yhteisön tunnistus- ja keskeisyysalgoritmit ajetaan täyden projisoidun graafin yli, ei vain aligraafin. Graafille, jossa on kymmeniä miljoonia solmuja, nämä algoritmit täytyy ajoittaa tausta-erätyöinä, ei interaktiivisina kyselyinä. Tulokset — communityId ja degreeCentrality kirjoitetaan takaisin solmuominaisuuksiksi — ovat sitten saatavissa välittömästi hakemistona analyytikkokyselyissä ilman algoritmin uudelleen ajamista.

Tietograafien integrointi C2- ja OSINT-putkistoihin

Tietograafi, joka ei ole kytketty reaaliaikaisiin tietolähteisiin, on historiallinen artefakti eikä operatiivinen työkalu. Integrointiarkkitehtuurissa on kolme syöttökanavaa ja kaksi kulutuspistettä.

CTI-syötteen ingestion (STIX/TAXII). TAXII-asiakas pollaa rekisteröityjä kokoelmaendpointteja — liittoutuneiden CTI-jakamisalustoja, kansallisia uhkatiedustelusyötteitä — ja käsittelee saapuvat STIX-paketit yllä kuvatun SDO-solmuun / SRO-kaareen muunnosputkiston kautta. Pakettikäsittely on idempotentti: MERGE STIX-tunnuksen perusteella varmistaa, että uudelleenlähetetty objekti päivittää ominaisuudet sen sijaan, että luo duplikaattisolmun. Uudet objektit käyvät läpi saman entiteettien ratkaisuputkiston kuin mikä tahansa muu lähde ennen sitoutumista; jos uusi STIX ThreatActor vastaa olemassa olevaa ei-STIX Person -solmua todennäköisyyspohjaisen identiteetin ratkaisun kautta, nämä kaksi yhdistetään ja molempien tietueiden kaikki kaaret ovat nyt traversoitavissa kanonisesta solmusta.

HUMINT-raportin ingestion. Luonnollisen kielen raportit ihmislähteistä käsitellään NLP-putken kautta, joka suorittaa nimettyjen entiteettien tunnistuksen, suhteen extraktion ja viittauksienresolution, sitten yhdistää ekstraktoidut entiteetit ja suhteet graafiskeemaan. NLP-putkisto ei ole graafi: se on transformaatiokerros proosasta strukturoituihin graafiolementteihin. Ekstraktoidut entiteetit käyvät läpi saman entiteettien ratkaisuputkiston kuin mikä tahansa muu lähde, tyypillisesti alhaisemmalla perusluottamuksella (proosaexktraktio on vähemmän luotettavaa kuin strukturoitu tietokantamerkintä), joka propagoituu HUMINT-raportin tukemiin kaariin.

SIGINT-raidan ingestion. SIGINT-havainnot — viestintä kahden päätepisteen välillä tietyllä hetkellä, laite ilmestyminen tietyssä sijainnissa — saapuvat suoratoistona. Jokainen havainto luo tai päivittää kaaren graafissa: COMMUNICATES_WITH-kaari kahden henkilö- tai laitesolmun välillä tai OBSERVED_AT-kaari laitteen ja sijainnin välillä. Kaaren valid_from on havaintoaikaleima; valid_until on null, ellei SIGINT-syöte nimenomaisesti sulje havaintoa. Suurivolyyminen suoratoistoingestio vaatii jonopohjaisen ingestorin (Kafka tai vastaava), joka puskuroi havainnot ja eräajaa ne graafiin kirjoitusnopeudella, jonka tietokanta voi absorboida ilman interaktiivisten kyselyjen estämistä.

Kaksi kulutuspistettä ovat analyytikkotyöasema ja C2:n yhteinen operatiivinen kuva (COP).

Analyytikkotyöasema tarjoaa linkkianalyyttisen käyttöliittymän, jossa analyytikko määrittää siemenenentiteetin, valitsee suhdetyypit ja luottamuskynnykset ja laajentaa rajatun naapuruston. Tulos renderöidään voimasuuntautuneena graafin asetteluna, jossa luottamus koodataan kaaren läpinäkyvyydeksi ja yhteisönjäsenyys solmun väriksi. Keskeisyyspisteet määrittävät solmun koon. Analyytikko ei koskaan näe koko graafin — vain rajatun, suodatetun, kyselyvetoisen aligraafin, joka vastaa tiettyyn kysymykseen. Hyvä käyttöliittymä näyttää Cypher-kaavion sivupalkissa, jotta analyytikko ymmärtää täsmälleen mitä kyeltiin ja voi tarkentaa sitä.

C2 COP -integraatio näyttää graafista johdetut entiteettiprofiilit — yksikön tunnetut alaiset, yksilön yhteisöjäsenyys, toimipisteen toimitusriippuvuudet — popupeina taktisessa kuvassa. Kun operaattori klikkaa seurattua entiteettiä, C2-järjestelmä kyselee tietograafista kyseisen entiteetin verkkokontekstin ja näyttää viisi suurinta luottamuksen ja keskeisyyden perusteella arvioitua liittyvää entiteettiä. Tämä muuttaa tietograafin itsenäisestä analyyttisesta työkalusta operatiivisen kuvan aktiiviseksi komponentiksi: strukturoitu suhdeintelligenssi, kontekstissa saatavilla, ilman että operaattori tarvitsee avata erillisen työkalun.

Arkkitehtuuriperiaate: Tietograafi ei ole visualisointi — se on datakerros. Sijoita ingestoinnin laatuun, entiteettien ratkaisun tarkkuuteen ja indeksin suorituskykyyn. Visualisointi on viimeinen maili. Analyytikkoliittymä, joka on rakennettu huonosti ratkaistun graafin ja matalan luottamuksen kaarien päälle, harhajohdetaan nopeammin ja itsevarmemmin kuin mikään manuaalinen prosessi, jonka se korvaa. Graafi ansaitsee operatiivisen luottamuksen auditoitavuuden kautta: jokainen näytetty yhteys on laajennettavissa sen taustalla oleviin todisteisiin, joihin on liitetty lähde, keräysaika ja luottamus.

Tuo suhdeintelligenssi operatiiviseen kuvaasi

Corvus HEAD yhdistää monilähteisen tiedustelun kyselykelpoiseeksi tietograafiksi — entiteettien ratkaisu, linkkianalyysi ja C2-integroitu verkon visualisointi, joka on rakennettu analyytikoille, jotka tarvitsevat auditoitavia, luottamuspainotteisia vastauksia, ei sekamelskaa.

Tutustu Corvus HEAD:iin → Varaa esittely

Tämän analyysin ovat valmistelleet Corvus Intelligencen insinöörit, jotka rakentavat kriittisiä tiedustelu- ja dataintegraatiojärjestelmiä puolustus- ja valtionhallinnon organisaatioille. Lue lisää tiimistämme →

Usein kysytyt kysymykset

Miksi relaatiotietokannan JOIN-räjähdykset tekevät niistä sopimattomia sotilaslinkkianalyysiin syvyydessä?

Relaatiotietokannat vastaavat suhteisiin liittyviin kysymyksiin JOIN-operaatioiden avulla, jotka kertovat työsarjan jokaisella hypyllä. Kahden hypyn kysely vaatii yhden itse-joinin; viiden hypyn kysely vaatii neljä, ja jokainen kertoo edellisen tuloksen mahdollisesti suurella laajentumistekijällä. Kymmentä miljoonaa entiteettitietuetta sisältävässä taulussa viiden hypyn traversointi voi tuottaa biljoonien rivien välituloksia ennen suodatusta. Tiedustelun linkkianalyysi tarvitsee rutiininomaisesti viisi tai useampia hyppyjä — siepattavalta puhelimelta sen yläpuolella olevien verkostojen verkostoon — mikä tekee relaation syvyyskyselyistä joko erittäin hitaita tai operatiivisesti mahdottomia istunnon aikana.

Mikä on ominaisuusgraafin ja RDF/OWL-tietograafin ero sotilaskontekstissa?

Ominaisuusgraafi tallentaa solmut ja kaaret tyypitetyillä merkinnöillä ja mielivaltaisilla avain-arvo -ominaisuuksilla molemmissa. Se on skeema-joustava ja optimoitu traversointikyselyihin. RDF-tietograafi mallintaa kaiken subjekti-predikaatti-objekti -kolmikoina; OWL lisää ontologiakerroksen, jolla on muodollinen semantiikka, joka tukee päättelyä. Sotilastiedustelulle ominaisuusgraafat ovat operatiivisesti käytännöllisempiä: ne käsittelevät alkuperä- ja luottamusominaisuuksia luonnollisesti ja integroituvat Cypher-työkaluihin, joita analyytikot jo käyttävät. RDF/OWL on suositeltava silloin, kun muodollinen standardien yhteentoimivuus on tärkeää, kuten STIX-sisällön integroinnissa semanttisella tasolla tai liittoutuneiden tietopohjien yhdistämisessä linked-data-protokollien avulla.

Miten entiteettien yksiselitteistäminen eroaa entiteettien ratkaisusta tiedustelukontekstissa?

Entiteettien ratkaisu päättää, viittaavatko kaksi strukturoitua tietuetta samaan todellisen maailman entiteettiin ja yhdistää ne. Entiteettien yksiselitteistäminen yhdistää tekstimaininnan — nimen HUMINT-raportissa — olemassa olevaan grafisolmuun. Molemmat täytyy ratkaista järjestyksessä: NLP ekstraktoi maininnat, yksiselitteistäminen yhdistää ne ehdokkaisiin solmuihin ja ratkaisu päättää, ovatko ehdokkaat sama entiteetti. Virheet yksiselitteistämisessä luovat vääriä kaaria; virheet ratkaisussa pirstovat tai yliyhdistelevät solmuja. Molemmat vaativat luottamuspisteet ja peruutettavat päätökset, täydellisellä tarkistuskirjauksella siitä, mikä todiste ajoi kunkin päätöksen.

Miltä STIX-suheobjekti näyttää graafikaareksi neo4j:ssä?

STIX SRO muuttuu suunnatuksi kaareksi, jonka tyyppi on relationship_type-merkkijono (esim. "uses", "targets"). SRO:n oma STIX-id, luottamus, created- ja modified-kentät tallennetaan kaaren ominaisuuksiksi. source_ref ja target_ref ratkeavat olemassa oleviin solmuihin niiden stix_id-ominaisuuden perusteella. Ajalliset kentät (valid_from, valid_until) indeksoidaan kaaren ominaisuuksiksi, jotta aikasuodatetut Cypher-kyselyt voivat suodattaa tietyn operaatioikkunan aikana aktiiviset suhteet. Peruutetut SRO:t asettavat revoked: true kaareen ja suljetaan pois traversoinneista oletuksena WHERE NOT -suodattimella, mutta säilytetään auditointia varten.

Miten versioituneita STIX-objekteja käsitellään graafivarastossa?

STIX-versiointi käyttää samaa tunnusta uudella muokatulla aikaleimalla. Kaksi strategiaa sopii. Tilannekuvien korvaaminen säilyttää vain kunkin solmun uusimman version — yksinkertainen, mutta menettää historian. Ajallinen solmuversiointi luo uuden solmuversion kutakin muokattua aikaleimaa kohden ja ketjuttaa versiot HAS_VERSION-kaarilla, mahdollistaen aikamatkustuskyselyt minkä tahansa menneen tiedustelukuvan rekonstruoimiseksi. Operatiiviselle tiedustelulle tilannekuvien korvaaminen riittää; analyyttisille työnkuluille, jotka tarvitsevat jäljittää, miten uhkakuva kehittyi ennen päätöstä, ajallinen versiointi on välttämätön. Molemmat strategiat täytyy merkitä peruutetut objektit revoked: true -arvolla ja estää ne traversoinneista poistamatta niitä, jotta auditoinnin jälki säilyy.

Mikä on supersolmuongelma sotilastiedustelugraafeissa?

Supersolmu on solmu, jolla on erittäin korkea aste — jaettu julkinen puhelinlinja, yhteinen NAT-IP tai suuri logistiikkakeskus. Supersolmun kautta traversointi kertoo tulosjoukon sen asteella, jolloin kyselyt eivät pääty. Keskeisyysanalyysissä supersolmu näyttää tärkeimpänä entiteettinä, vaikka se heijastaa infrastruktuuriartefaktia, ei operatiivista merkitystä. Lieventämiskeinoja ovat per-solmulaajennuksen asteen rajoittaminen, ylläpitohakemiston ylläpitäminen tunnetuille jaettujen resurssien solmuille ja asteella painotettu kaarisuodatus, jotta hyvin korkea-asteiset solmut vaikuttavat vähemmän polkupisteytyksiin.

Mikä graafiTietokanta sopii parhaiten ilmarakoituneisiin sotilastiedustelukäyttöönotoihin?

Ilmarakoihin käyttöönotoihin tarvitaan graafijärjestelmä, jossa ei ole verkon lisensointikutsuja. Neo4j Enterprise offline-lisenssillä on analyytikkotyökalun kanssa yhteensopivampaa. TigerGraph tukee paikan päällä olevaa pakettilisensointia. JanusGraph on täysin avoimen lähdekoodin ja toimii upotetun RocksDB:n yli — ihanteellinen reunakäyttöön. Amazon Neptune on pilvipalvelu, joka ei sovi todelliseen ilmarakoon. Eteenpäin sijoitetuille reunasolmuille JanusGraph RocksDB:llä tarjoaa pienimmän jalanjäljen. Varuskunta-analyyttisille verkoille Neo4j Enterprise -klusterointi tai TigerGraph-hajautettu tarjoaa tarvittavan monen analyytikon samanaikaisuuden.

Mikä Cypher-kaavio löytää lyhyimmän tiedustelupolun kahden entiteetin välillä?

Kanoninen kaavio on: 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. [*1..6]-sidonta estää villien traversointien. Luottamuspainotetuille lyhyimmille poluille GDS Dijkstra -proseduuri painoominaisuudella (1-luottamus) suosii korkean luottamuksen kaaria antamalla niille alemman kustannuksen.

Miten yhteisön tunnistus auttaa analyytikoita priorisoimaan kohteita?

Yhteisön tunnistusalgoritmit — Louvain, merkinnän propagointi, heikosti yhtenäiset komponentit — jakavat graafin klustereihin, jotka ovat sisäisesti tiheämmin yhteydessä kuin ulkoisesti. Sotilastiedustelussa yhteisö vastaa tyypillisesti toiminnallista solua: viestivät yksilöt, resursseja jakava logistiikkaverkko tai toimitusketjuilla yhdistetyt toimipisteet. Louvainerin ajaminen palvelinpuolella ja communityId:n kirjoittaminen solmuominaisuudeksi antaa analyytikoille mahdollisuuden löytää välittömästi kaikki siemenenentiteetin yhteisötoverit, tunnistaa korkean välisyyden siltasolmut, jotka yhdistävät muuten erillisiä klustereja, ja priorisoida keräyksen yhteisöjohtajia kohti sisäisen yhteisön asteen keskeisyyden perusteella.

Miten CTI-syötteet ja reaaliaikaiset SIGINT-radat sovitetaan yhteen elävässä tietograafissa?

CTI-syötteet saapuvat STIX-paketteina, jotka käsitellään erässä; SIGINT saapuu jatkuvana virtana. Kaksivaiheinen putkisto sovittaa molemmat yhteen. Erävaiheen käsittelee STIX-paketit: MERGE STIX-tunnuksen perusteella luo tai päivittää solmut, SRO:t muuttuvat kaariksi. Suoratoistovaiheen käsittelee SIGINT-havainnot Kafka-pohjaisen ingestorin kautta: jokainen havainto entiteetin ratkaisulla lähes reaaliajassa ja luo aikasidotun kaaren. Molemmat vaiheet kirjoittavat samaan ominaisuusgraafiin, joten Cypher-kyselyt näkevät yhtenäisen kuvan. Graafin ajalliset kaariominaisuudet eristävät viimeisimmän suoratoistosta aikaikkuna ilman erähistorian uudelleen ajamista.