CTI-jakamisen automatisointi: STIX, TAXII ja puolustustiedusteluputki

Uhkatieto menettää arvoaan tunti tunnilta. Kompromettoitumisindikaattori, joka varoittaa yhtä organisaatiota maanantaina, on hyödytön kumppanille, joka saa sen PDF-liitteenä perjantaina. Kyberuhkatiedon (CTI) jakamisen koko pointti on tiivistää tuo aikaväli sekunneiksi – siirtää validoitu indikaattori sen löytäneeltä analyytikolta jokaisen luotetun kumppanin havaintopinoon ennen kuin vastustaja vaihtaa infrastruktuuria. Se on automaatio-ongelma, ja kaksi standardia, jotka tekevät automaatiosta mahdollista, ovat STIX ja TAXII. Tämä artikkeli käy läpi automatisoidun CTI-jakamisputken arkkitehtuurin puolustusorganisaatiolle: miten mallintaa objekteja, vastaanottaa syötteitä, rikastaa ja korreloida indikaattoreita ja työntää tulos työkaluihin, jotka tosiasiassa estävät liikennettä ja nostavat hälytyksiä.

STIX ja TAXII: tietomalli ja siirto

Nuo kaksi standardia mainitaan jatkuvasti yhdessä, mutta ne ratkaisevat eri ongelmia. STIX (Structured Threat Information eXpression) on tietomalli. Se määrittelee joukon tyypitettyjä objekteja – STIX-domain-objekteja, kuten indicator, malware, threat-actor, attack-pattern ja campaign – sekä STIX-relationship-objekteja, jotka yhdistävät ne graafiksi. Yksittäinen STIX 2.1 -indicator-objekti kantaa kuviota (koneluettava havaintolauseke), kelpoisuusikkunaa, luottamuspisteitä ja TLP-merkintää, kaikki JSON-rakenteessa, jonka mikä tahansa yhteensopiva järjestelmä voi jäsentää ilman erillistä adapteria.

TAXII (Trusted Automated eXchange of Intelligence Information) on siirtoprotokolla. Se määrittelee RESTful-HTTPS-API:n STIX-nippujen vaihtamiseen järjestelmien välillä kahden abstraktion kautta: kokoelmat (vetomalli, jossa asiakas kyselee palvelimelta suodatinta vastaavia objekteja) ja kanavat (julkaise–tilaa-malli). Automatisoidussa jakamisessa tyypillinen kuvio on TAXII 2.1 -palvelin, joka tarjoaa useita kokoelmia – segmentoituina luokituksen ja julkaisuvaltuuden mukaan –, joita kumppaniasiakkaat kyselevät aikataulun mukaan.

Erottelu on tärkeä putken suunnittelulle, koska nuo kaksi standardia epäonnistuvat toisistaan riippumatta. Putki voi tuottaa täydellisen kelvollista STIX:iä, jota yksikään kumppani ei voi noutaa, koska TAXII-palvelin on väärin konfiguroitu, tai sillä voi olla virheetön TAXII-siirto, joka kantaa STIX-nippuja, jotka eivät läpäise skeemavalidointia toisessa päässä. Molemmat kerrokset tarvitsevat automatisoidun validoinnin ennen kuin mitään lähtee rakennuksesta.

Putken arkkitehtuuri: vastaanota, rikasta, korreloi, julkaise

Automatisoitu CTI-jakamisputki on neljä vaihetta, jotka yhdistää yhteinen objektivarasto. Sama STIX-linjattu skeema virtaa niiden kaikkien läpi, mikä tekee päästä päähän -automaatiosta hallittavaa.

Vastaanotto. Putki vetää heterogeenisistä lähteistä: kansallisten CERT:ien ja luotettujen kumppaneiden julkaisemista TAXII-kokoelmista, kaupallisista syötteistä, jotka tuottavat CSV:tä tai omaa JSON:ia, SOC:n sisäisestä telemetriasta ja strukturoiduista CTI-alustan vienneistä. Jokainen lähde saa oman adapterin, jonka ainoa tehtävä on normalisoida sen natiivimuoto kanoniseen sisäiseen skeemaan ja leimata alkuperämetatiedot – lähde, keräysaikaleima, luottamus ja TLP-merkintä. Tämän vaiheen ei-neuvoteltavissa oleva sääntö on deduplikointi avaimena havaittava kuvio eikä STIX-objektin tunnus, koska sama haitallinen IP saapuu tusinasta syötteestä tusinalla eri tunnuksella.

Rikastus. Raaka indikaattori on datapiste; rikastettu indikaattori on tiedustelua. Rikastustyöntekijät liittävät passiivisen DNS-historian, WHOIS:n, ASN-attribuution, geopaikannuksen, mainepisteet ja linkit tunnettuihin haittaohjelmaperheisiin. STIX-termein rikastus tuottaa lisäobjekteja ja -suhteita, jotka roikkuvat alkuperäisestä indikaattorista – relationship autonomisen järjestelmän objektiin, note, joka kirjaa mainehaut. Rikastuksen on toimittava asynkronisesti ja välimuistitettava aggressiivisesti; hidas WHOIS-haku ei saa antaa viivästyttää kiireellisen indikaattorin julkaisua.

Korrelointi. Korrelointivaihe lataa objektit ja suhteet graafivarastoon ja etsii rakennetta: infrastruktuuria jakavia indikaattoreita, kampanjoiden yli uudelleenkäytettyä infrastruktuuria, tekniikoita, jotka sormenjäljentävät tunnetun toimijan. MITRE ATT&CK -kartoitus on yhdistävä kudos – jokainen attack-pattern-objekti viittaa ATT&CK-tekniikan tunnukseen, mahdollistaen sekä toimijaprofiloinnin että havaintokattavuuden aukkoanalyysin. Tämä vaihe myös laskee tai välittää luottamuksen ja soveltaa vanhenemisikkunoita, jotta atomiset indikaattorit ikääntyvät pois automaattisesti sen sijaan, että kasaantuisivat vanhentuneeksi estolistaksi.

Julkaisu. Tulostusvaihe tekee kaksi asiaa samanaikaisesti. Se tarjoaa TAXII 2.1 -palvelimen kokoelmilla, jotka on segmentoitu TLP:n ja julkaisuvaltuuden mukaan, suodattaen jokaisen lähtevän objektin merkinnän ja vähimmäisluottamuksen mukaan ennen kuin se voi lähteä. Ja se työntää korkean luottamuksen indikaattorit suoraan havaintotyökaluihin, kääntäen STIX-kuviot alla kuvattuihin natiiveihin sääntökieliin.

Indikaattorien mallintaminen STIX-objekteina

Skeeman sydän on STIX-indicator-objekti, ja kenttä, joka tekee työn, on pattern. STIX 2.1 -kuviointi on pieni kyselykieli: [ipv4-addr:value = '203.0.113.10'] kuvaa yhden haitallisen osoitteen, kun taas yhdistelmäkuvio voi ilmaista "tämä verkkotunnus JA tämä tiedostotiiviste havaittu yhdessä." Putken on validoitava jokainen generoitu kuvio STIX-kuviointikielioppia vastaan ennen julkaisua, koska virheellinen kuvio epäonnistuu hiljaa täsmäämään mihinkään, kun kumppani ottaa sen käyttöön.

Kuvion lisäksi kolme ominaisuutta on pakollisia puolustusjakamiselle. confidence on kokonaisluku 0:sta 100:aan, jonka on välityttävä muuttumattomana jokaisen uudelleenjulkaisun läpi. valid_from ja valid_until rajaavat indikaattorin operatiivisen elinkaaren. Ja viittaus marking-definition-objektiin kantaa TLP-tason. Indikaattori ilman näitä kolmea ei ole jaettavissa puolustuskontekstissa – vastaanottavalla järjestelmällä ei ole tapaa päättää, saako se uudelleenjakaa objektin tai kuinka kauan luottaa siihen.

Luottamus, TLP ja luottamusongelma

Automaatio vahvistaa virheet. Ihmisanalyytikko, joka saa epämääräisen yhden lähteen indikaattorin, käyttää harkintaa ennen toimimista; automatisoitu putki, joka työntää jokaisen vastaanotetun indikaattorin suoraan kumppanin palomuureihin, estää ennemmin tai myöhemmin laillisen palvelun, koska yksi heikkolaatuinen syöte luokitteli sen väärin. Puolustukset tätä vastaan ovat luottamuspisteytys ja Traffic Light Protocol -käsittely, ja molemmat on pakotettava mekaanisesti.

Luottamuspisteytyksen tulisi olla suunnittelultaan monilähteistä. Viiden riippumattoman syötteen ilmoittama ja sisäisellä telemetrialla vahvistettu indikaattori ansaitsee korkeat pisteet; vahvistamaton yhden lähteen indikaattori pysyy matalana ja pidätetään automaattisesta estosta, vaikka se silti jaetaan analyytikon tarkasteluun. Pisteytysfunktio on osa korrelointivaihetta, ei jälkikäteinen ajatus.

TLP-käsittely ohjaa uudelleenjakelua. Putken on suodatettava lähtevä jakaminen merkinnän mukaan: TLP:RED ei koskaan poistu alkuperäisestä enklaavista, TLP:AMBER menee vain nimetyille kumppaneille, TLP:GREEN luotetulle yhteisölle, TLP:CLEAR kenelle tahansa. Merkinnän poistaminen tai alentaminen uudelleenjulkaisussa on vakava tapaus, joten merkinnän on matkustettava objektin mukana muuttumattomana STIX-marking-definition-viittauksena, ei koskaan muuttuvana kenttänä, jonka adapteri voisi vahingossa pudottaa. Julkaisuvaltuus ja puolustuskäyttöönottojen luokitusmerkinnät matkustavat samassa rakenteessa.

Indikaattorien työntäminen havaintotyökaluihin

STIX:n jakaminen kumppaneiden kanssa on vain puolet arvosta; toinen puoli on indikaattorien operationalisointi omassa havaintopinossasi. STIX-kuvio ei ole suoraan ajettavissa SIEM:llä tai palomuurilla, joten putki tarvitsee käännöskerroksen, joka tuottaa kunkin työkalun natiivin sääntökielen.

Korkean luottamuksen atomiset indikaattorit – IP:t, verkkotunnukset, tiedostotiivisteet – muuttuvat estolistamerkinnöiksi palomuureissa ja DNS-resolvereissa sekä seurantalistamerkinnöiksi SIEM:ssä. Verkkoyhteyttä täsmäävä STIX-kuvio kartoittuu Sigma-säännöksi tai Splunk-SPL-hauksi; tiedostotiiviste-kuvio kartoittuu päätelaitteen havaintokyselyksi. Käyttäytymisindikaattorit, jotka ilmaistaan ATT&CK-kartoitettuina attack-pattern-objekteina, muuttuvat korrelointilogiikaksi yksinkertaisten estolistojen sijaan, koska ne kuvaavat toimintasarjaa yhden huonon arvon sijaan. Tämä on sama rikastuksesta-havaintoon-polku, jota LLM-avusteinen luokittelu voi nopeuttaa strukturoimalla sotkuiset lähderaportit puhtaaksi STIX:ksi ennen kuin ne edes saavuttavat käännöskerroksen.

SOAR-kerroksen (Security Orchestration, Automation and Response) tulisi omistaa käyttöönotto ja, kriittisesti, takaisinveto. Ylivoimaisesti yleisin operatiivinen vika indikaattorien toimituksessa on takaisinveton puuttuminen: indikaattorit työnnetään havaintotyökaluihin eikä koskaan poisteta, joten estolista kasvaa rajatta ja alkaa lopulta tuottaa vääriä positiivisia kuukausia sitten vanhentuneista indikaattoreista. Putken on seurattava, mitkä indikaattorit on otettu käyttöön missäkin työkaluissa, ja vedettävä ne automaattisesti takaisin, kun valid_until ohittuu tai luottamus laskee kynnyksen alle.

Validointi ja valvonta rajoilla

Jokainen automatisoitu vaihto tarvitsee suojakaiteet kahdessa saumassa, joissa data tulee sisään ja lähtee ulos. Vastaanotossa jokainen saapuva STIX-nippu validoidaan 2.1-skeemaa vastaan ja jokainen kuvio kuviointikielioppia vastaan ennen kuin se koskettaa objektivarastoa; syöte, joka alkaa tuottaa virheellisiä objekteja, on asetettava karanteeniin automaattisesti sen sijaan, että se myrkyttäisi graafin. Julkaisussa sama validointi ajetaan uudelleen generoiduille objekteille, plus merkintä- ja luottamusportti, jota mikään polku ei saa ohittaa. Näiden välissä putken tulisi tuottaa operatiivisia metriikoita – vastaanottovolyymi lähdettä kohden, deduplikointisuhde, rikastusviive, aika vastaanotosta julkaisuun ja kokoelmakohtaiset lähtevät määrät –, jotta analyytikko näkee yhdellä silmäyksellä, milloin kumppanisyöte on hiljentynyt tai milloin julkaisuviive on hiipinyt tavoitteensa yli. Hiljainen vika on automaation vihollinen: TAXII-kysely, joka hiljaa palauttaa tyhjää viikon ajan, näyttää identtiseltä syötteen kanssa, jolla ei ole uutta tiedustelua, ellei putki tarkkaile sitä.

Putken ajaminen luokitellulla puolella

Puolustusorganisaatioille suuri osa tästä putkesta ajetaan luokitellussa enklaavissa ilman internet-polkua. Arkkitehtuurirajoite on ehdoton: minkään putken komponentin ei saa vaatia ulkoista verkkokutsua ajon aikana. STIX-objektivarasto, rikastustyöntekijät, korrelointigraafi ja TAXII-palvelin toimivat kaikki enklaavin sisällä. Ulkoiset kumppanisyötteet tulevat sisään allekirjoitettuina STIX-nippuina hyväksytyn cross-domain-ratkaisun kautta eikä reaaliaikaisena TAXII-kyselynä rajan yli, ja lähtevä jakaminen viedään nippuina valvottua siirtoa varten sen sijaan, että kumppani vetäisi suoraan kehän sisältä.

Tämä kääntää normaalin oletuksen, että rikastus voi tavoittaa mainerajapinnan pyynnöstä. Ilmaeristetyssä käyttöönotossa jokainen rikastuslähde – passiiviset DNS-tietokannat, ASN-taulukot, maine-tilannekuvat – on peilattava paikallisesti ja päivitettävä saman valvotun siirtopolun kautta, joka kantaa uhkasyötteet. Suunnittelu offline-toimintaa varten päivästä yksi on paljon halvempaa kuin sen jälkikäteen lisääminen, koska vaihtoehto on havaita akkreditoinnin aikana, että puolet rikastuspinosta olettaa hiljaa lähtevän HTTPS:n.

Hyvin tehtynä automatisoitu STIX/TAXII-putki muuttaa CTI-jakamisen manuaalisesta, häviöllisestä, tuntien mittaisesta prosessista kone-koneeseen-vaihdoksi, jota mitataan sekunneissa – samalla kun hallintoportti varmistaa, ettei nopeus koskaan maksa organisaatiolle sen hallintaa siitä, mitä se jakaa ja mitä se estää.