Dirbtinis intelektas kaip gynyba: kur DI kibernetiniame saugume iš tikrųjų padeda

Ankstesniuose straipsniuose nagrinėjome, kaip dirbtinį intelektą naudoja užpuolikai: fišingui, suklastotiems balsams, viešos informacijos rinkimui ir pažeidžiamumų paieškai. Tai tik viena vaizdo pusė.

Gynybos pusėje dirbtinis intelektas (toliau – DI) sveria lygiai tiek pat. Tai įrankis. Gynėjo rankose jis gerina kibernetinį saugumą: atsijoja įtartinus laiškus, perskaito įvykių žurnalų kalnus, sutrumpina reagavimo laiką ir nuima nuo komandos dalį rankų darbo.

Užpuoliko pusę aprašo du straipsniai: DI kaip užpuolikas ir LLM integracijų įsilaužimų testavimas.

Socialinės inžinerijos pusę – trys praktiniai vadovai: kas yra DI fišingas, „deepfake“ sukčiavimas ir vishingas bei OSINT ir DI.

Kodėl saugumo komandai rankų nebeužtenka

Šiuolaikinė organizacija be perstojo palieka skaitmeninius pėdsakus: elektroninio pašto susirašinėjimą, prisijungimus, debesijos įvykius, tinklo srautą, aplikacijų ir darbo vietų žurnalus, teisių pakeitimus, nepavykusius prisijungimo bandymus ir saugumo įrankių įspėjimus.

Nedidelėje įmonėje per dieną susidaro tūkstančiai įvykių, didelėje organizacijoje – milijonai. Rankomis jų neperžiūri niekas. Būtent čia prasideda DI vaidmuo kibernetiniame saugume: randami dėsningumai, nuokrypiai ir sąsajos tokiame duomenų kiekyje, kurio žmogus nebeaprėpia.

Lietuvoje prisideda dar viena aplinkybė, ir ji pakeičia pokalbį. Vidutinis pirkėjas neturi savo saugumo operacijų komandos: IT – vienas ar du žmonės, dalis priežiūros perduota partneriui, o saugumo įrankių vaidmuo dažnai apsiriboja tuo, kas jau įeina į „Microsoft 365“ arba „Google Workspace“ licenciją. Todėl, kai pasiūlyme atsiranda „DI mūsų saugumo operacijų centre“, verta paklausti paprasto dalyko: kuris žmogus žiūrės to įrankio įspėjimus penktadienio vakarą ir kiek laiko jis tai darys, kol pradės juos uždarinėti neskaitęs.

Kaip DI atpažįsta fišingą

Fišingas (liet. duomenų viliojimas, angl. phishing) – tai sritis, kurioje gynybos pusėje DI duoda daugiausia. Šiuolaikinis fišingo filtras nebeieško vien žinomų kenksmingų nuorodų. Vertinama laiško kalba, siuntėjo reputacija, domeno panašumas, priedo tipas, nuorodos elgsena ir dar keliolika kitų požymių.

Į patikrą patenka ir laiškas, kuriame nėra jokio žinomo viruso, bet kažkas vis tiek nesutampa: jis skubina, prašo prisijungimo duomenų, veda į neįprastą nuorodą arba apsimeta vidiniu susirašinėjimu.

Nė vienas filtras nesugauna visko. Technologija verta tiek, kiek už jos stovi apmokyti žmonės: filtras nukrato atakų masę, o tai, kas prasismelkia, atpažįsta jau žmogus.

Kodėl lietuvių kalba nebėra požymis

Lietuvoje metų metus veikė vienas paprastas matas. Jei laiškas buvo lietuviškas be nosinių, su svetimais sakinio modeliais ir su žodžiais, kurių gyvas žmogus nevartoja, tai buvo sukčiavimas. Pagal šį požymį darbuotojai ir mokėsi atpažinti atakas, o daugelyje mokymo skaidrių jis iki šiol stovi pirmoje vietoje.

Šis matas dingo. Kalbos modelis lietuviškai rašo taisyklingai: su nosinėmis ir ilgosiomis, su tvarkingais linksniais, įstaigos ar buhalterijos tonu ir Lietuvoje vartojamu žodynu. Užpuolikui nebereikia lietuviškai mokančio žmogaus komandoje, ir būtent tai yra pokyčio esmė. Anksčiau nedidelė kalba pati savaime buvo barjeras – nedidelis, bet realus. Dabar pakanka vieno nurodymo modeliui.

Iš to plaukia dvi išvados. Pirma: mokymuose nebeverta liepti žmonėms ieškoti kalbos klaidų, nes šis požymis suveikia vis rečiau. Antra – mažiau pastebima. Komercinių filtrų kalbos modeliai daugiausia mokyti anglų kalbos medžiaga, todėl lietuviškame laiške kalbos požymis yra silpnesnis nei angliškame.

Techniniai požymiai, priešingai, nesikeičia. Siuntėjo domeno amžius ir panašumas į tikrąjį, domeno autentiškumo įrašai SPF, DKIM ir DMARC, atsakymo adresas, nesutampantis su siuntėjo adresu, tikrasis nuorodos tikslas ir priedo tipas veikia vienodai lietuviškai, angliškai ir bet kuria kita kalba. Būtent jais nedidelės kalbos rinkoje ir verta remtis. Renkantis įrankį, tiekėjui verta užduoti vieną klausimą: kaip filtras dirba su lietuvių kalba ir kokia medžiaga jis apmokytas? Atsakymas „modelis yra daugiakalbis“ nėra atsakymas.

Ką DI pastebi stebėsenoje

Saugumo stebėsena seka, kas vyksta sistemose. DI čia išryškina neįprastą elgseną ir padeda aptikti grėsmes.

Keli tipiniai požymiai:

• naudotojas prisijungia iš šalies, iš kurios niekada anksčiau nesijungė,
• paskyra staiga atsisiunčia neįprastai daug duomenų,
• darbuotojas bando patekti į sistemą, kurios kasdien nenaudoja,
• įrenginys susisiekia su įtartinu domenu,
• naktį vienas po kito krinta nepavykę prisijungimo bandymai,
• administratoriaus paskyra atlieka neįprastus pakeitimus.

Vienas įvykis savaime dar nėra incidentas. DI, priešingai, sudeda požymius į vieną vietą ir parodo, kad jie jau sudaro vaizdą. Praktikoje tai veikia greta SIEM, EDR ir debesijos saugumo įrankių.

Lietuvos kontekste verta atsiminti vieną techninį niuansą. Geografinis nuokrypis pats savaime čia – triukšmas. Darbuotojai važiuoja į Latviją ir Lenkiją, naudoja mobilųjį internetą su kintančiu adresu, o nuotolinis darbas per užsienio paslaugų teikėją išoriniame adrese gali atrodyti kaip kita šalis. Modelis, nematęs įprasto darbo ritmo, pirmosiomis savaitėmis apie tokius dalykus praneša šimtus kartų. Todėl įrankiui pirmiausia reikia mokymosi laikotarpio ir žmogaus, kuris pasako, kas šioje organizacijoje yra normalu. Be jų rezultatas nuspėjamas: po mėnesio įspėjimų nebeskaito niekas.

Kaip DI pagreitina reagavimą į incidentus

Incidento metu laikas lemia viską. Komandai per trumpą laiką reikia suprasti, kas nutiko, ką tai paliečia, kurias sistemas atjungti ir koks yra kitas žingsnis.

DI sudeda įvykių seką, pasiūlo tęsinį, sudėlioja darbus pagal svarbą ir parengia trumpą santrauką sprendimų priėmėjams. Čia labiausiai praverčia LLM: analitikui nebereikia valandų valandas naršyti po žurnalus ir įspėjimus. Tai reagavimas į incidentus, kuriame pirmoji valanda praeina suprantant, kas įvyko, o ne ieškant, kur tai užrašyta.

Tokia santrauka atrodo maždaug taip: „Naudotojo paskyra perimta. Pirmiausia buvo prisijungimas iš neįprastos vietos, paskui sukurta nauja pašto persiuntimo taisyklė, galiausiai – bandymas pasiekti bendrinamus dokumentus.“

Laiko tai iš tikrųjų sutaupo. Rezultatą vis tiek patikrina žmogus.

Lietuvoje šis sutaupytas laikas turi konkrečią vertę. Daugumoje organizacijų nėra ištisą parą budinčios komandos, todėl pirmoji incidento valanda tenka vienam ar dviem žmonėms, o pirmasis pranešimas rašomas tada, kai vaizdas dar nepilnas. Būtent čia DI santrauka praverčia labiausiai: ji greičiau sudeda įvykių seką, iš kurios galima parašyti, kas jau žinoma ir kas dar ne. Ką į tą pranešimą įrašyti, sprendžia žmogus, nes klaidingas faktas kainuoja brangiau nei valanda vėlavimo.

Kaip DI padeda programuotojams

DI praverčia ir kuriant programinę įrangą. Peržiūrimas kodas, išryškinamos rizikingos vietos, siūlomas saugesnis sprendimas ir paprasta kalba paaiškinama problema.

Tai svarbu, nes saugumo specialistų yra mažai. Programuotojas dirba pagal terminą, o saugumas iš jo pozicijos dažnai atrodo kaip stabdys. Klaidą, kurią DI pagauna dar rašymo metu, ištaisyti pigiau ir greičiau nei tą pačią klaidą po incidento.

Kartu DI nėra pateisinimas silpnam procesui. Be kodo peržiūros, testavimo, saugumo reikalavimų ir aiškios atsakomybės jis neveikia. Ir dar viena riba: įrankis atpažįsta tik tai, ką jau matė. Teisių modelio spragos, kai vienas klientas mato kito užsakymus, jis nepastebi lygiai taip pat, kaip nepastebi ir spragų skenavimas – todėl, kad nežino, kas konkrečioje aplikacijoje leidžiama.

Prisideda ir nauja aplinkybė. Dalis kodo dabar gimsta tame pačiame DI pagalbininko lange, todėl dažniau pasitaiko klaidų, kurios anksčiau būdavo retesnės: perkopijuoti prieigos raktai, pasenusios bibliotekos ir pasiūlymai, kartojantys tai, kas internete dažniausia, o ne tai, kas saugiausia. Tai, kad kodą parašė DI, patikros žingsnių prieš publikavimą nekeičia.

Ką DI duoda darbuotojų mokymuose

Geri kibernetinio saugumo mokymai nėra kartą per metus perskaitytos nuobodžios skaidrės. DI padeda sudėlioti gyvus, bet saugius mokymo scenarijus.

Imituotus fišingo laiškus galima pritaikyti pagal vaidmenį: vienas buhalterijai, kitas pardavimams, trečias personalo skyriui. Taip darbuotojas treniruojasi situacijoje, su kuria iš tikrųjų susiduria savo darbe.

Lietuvoje prisideda kalbos klausimas, ir tai ne smulkmena. Jei mokomasis laiškas angliškas, o tikra ataka ateina lietuviškai, treniruojamas kalbos mokėjimas, o ne budrumas. Scenarijus verta rašyti lietuviškai ir su Lietuvoje atpažįstamu rėmu: tiekėjo sąskaita faktūra, laiškas neva iš buhalterijos, pranešimas apie siuntos pristatymą, valstybės įstaigos forma. Kaip tai vyksta praktikoje, aprašyta kibernetinio saugumo mokymų puslapyje, o platesnę atakos pusę dengia socialinės inžinerijos testavimas.

Kur DI baigiasi

DI klysta. Jis pameta kontekstą, incidentu pavadina kasdienį darbą arba per menkai įvertina realią riziką.

Gynybos pusėje didžiausios rizikos yra tokios:

• aklas pasitikėjimas rekomendacija,
• blogai sukonfigūruotas įrankis,
• trūkstama žmogaus priežiūra,
• jautrių duomenų nutekėjimas į netinkamą DI įrankį,
• klaidingi teigiami radiniai,
• neaiški atsakomybė.

Taisyklė paprasta: DI siūlo ir padeda, žmogus sprendžia.

Ketvirtasis punktas Lietuvoje dažniausiai atsiduria pas teisininką. BDAR požiūriu į viešą DI įrankį įkeltas klientų sąrašas, sutarties projektas ar incidento žurnalas – tai asmens duomenų tvarkymas su visomis iš to kylančiomis pasekmėmis: tvarkymo pagrindas, perdavimas už Europos ekonominės erdvės ribų, saugojimo terminas ir klausimas, ar įrankio teikėjas įvestą medžiagą naudoja modeliui mokyti. Priežiūros institucija šiais klausimais Lietuvoje – Valstybinė duomenų apsaugos inspekcija. Praktinė išeitis nėra visaapimantis draudimas, kurio vis tiek niekas nesilaiko, o trumpas sąrašas: kurie įrankiai patvirtinti, kokie duomenys juose gali atsidurti ir kas daroma su sutartimis, klientų duomenimis ir incidentų žurnalais.

Ką organizacijai verta įsivesti

1. Nuspręskite, kokie duomenys gali patekti į DI įrankius.

Jautriai informacijai ne vieta atsitiktinai pasirinktame viešame įrankyje. Sąrašas turi būti trumpas ir surašytas, kitaip jo neatsimena niekas.

2. Užsirašykite DI naudojimo taisykles.

Be jų kiekvienas sprendžia pats, o taisyklės atsiranda tik po pirmo nutekėjimo.

3. Naudokite DI ten, kur jis mažina riziką.

Fišingo filtras, stebėsena, incidentų santraukos, kodo peržiūra ir SOC automatizavimas.

4. Paskutinį žodį palikite žmogui.

Ypač incidento metu, blokuojant paskyrą ir priimant sprendimus, kurie paliečia veiklos tęstinumą.

5. Matuokite rezultatą.

Pasitikrinkite, ar incidentų iš tikrųjų sumažėjo, ar tik įspėjimų padaugėjo.

6. Klasikinė apsauga lieka.

Daugiaveiksnis autentifikavimas, atsarginės kopijos, atnaujinimai, mažiausių būtinų teisių principas ir zero trust tebėra pamatas. Nė vienam iš jų nereikia nė vieno DI įrankio.

Ar DI pakeičia saugumo kultūrą

Įrankiai gali būti puikūs. Jei niekas nežino, kam pranešti apie įtartiną laišką, jei mokėjimai tvirtinami skubotai ir jei paskyrose nėra daugiaveiksnio autentifikavimo, DI nepadės.

Kibernetinis saugumas susideda iš žmonių, proceso ir technologijos. DI priklauso technologijai, bet, kol jis neįaugęs į procesą ir kol žmonės jo nesupranta, jis pakeičia mažai.

Ko DI neįvykdo pagal Lietuvos reikalavimus

Vieną ribą verta įvardyti tiesiai, nes pirkimuose ji mėgsta susimaišyti.

Lietuvoje kibernetinio saugumo reikalavimus nustato Kibernetinio saugumo įstatymas (toliau – KSĮ). NIS2 direktyva perkelta ne atskiru teisės aktu, o šį įstatymą išdėstant nauja redakcija – įstatymu Nr. XIV-2902, kuris įsigaliojo 2024 m. spalio 18 d. Konkretūs organizaciniai ir techniniai reikalavimai surašyti Kibernetinio saugumo reikalavimų apraše, patvirtintame Vyriausybės nutarimu Nr. 945.

Apraše yra trys atskiros, reguliariai pasikartojančios pareigos, ir nė vienos iš jų DI įrankio išvestis nepakeičia. Pirma – visos informacinės sistemos pažeidžiamumų skenavimas ne rečiau kaip kas 6 mėnesius (45.8 papunktis). Antra – atitikties vertinimas kartą per metus, kurį subjektas atlieka pats sau (48.1 papunktis). Trečia – kibernetinio saugumo auditas ne rečiau kaip kas 3 metus (48.3 papunktis ir KSĮ 14 str. 8 d.). Nė viena iš šių trijų pareigų nėra įsilaužimų testas, ir pats įsilaužimų testavimas Lietuvos teisėje neprivalomas – testuotojų licencijavimo ar registro čia nėra.

Terminai taip pat skaičiuojami ne nuo visai rinkai bendros datos, o nuo kiekvieno subjekto registracijos Kibernetinio saugumo informacinėje sistemoje: 12 mėnesių organizaciniams reikalavimams ir 24 mėnesiai Apraše išvardytiems techniniams. Kiekvieno subjekto laikrodis eina savarankiškai, todėl viena visiems skelbiama data daugumai skaitytojų būtų klaidinga.

DI įrankiai šiame vaizde – kasdienės gynybos sluoksnis, o ne įrodymas. Įrodymą sukuria įsilaužimų testavimas su ataskaita, iš kurios matyti, kas buvo testuojama, kada, ką testuotojas rado ir kas su radiniais padaryta toliau. Kada toks testas prasmingas ir kam jis skirtas, plačiau išnagrinėta straipsnyje apie tai, ar įsilaužimų testavimas privalomas, o pasirengimo pusę dengia straipsnis apie kibernetinio saugumo auditą.

Antra pusė ne mažiau svarbi. Jei organizacija DI perka pati arba įdiegia jį į savo produktą, modelis tampa nauju atakos paviršiumi: prompt injection, tai yra modeliui paslėptos komandos, prieiga prie duomenų per įrankių integracijas ir per plačios teisės tarp modelio ir vidinių sistemų. Tai tikrina AI ir LLM integracijų saugumo testavimas, o ne įprasta aplikacijų peržiūra. Kaip generatyviniai modeliai praverčia pačiam analitikui, aprašyta straipsnyje apie generatyvinį DI kibernetinio saugumo analitikams.

Ir dar viena riba, kurią geriau pasakyti iškart. HAXORIS – Slovakijos įmonė. Mūsų darbas – techninis saugumo testavimas ir pasirengimo vertinimas; KSĮ 14 str. 8 d. numatyto kibernetinio saugumo audito neatliekame ir sertifikatų neišduodame.

DI nėra autopilotas be vairuotojo

Didžiausia klaida – manyti, kad DI viską sutvarkys pats. Saugumui reikia konteksto: kurios sistemos yra kritinės, kas turi prieigą, kas yra normali elgsena ir kas yra išimtis.

Todėl svarbus human-in-the-loop principas, tai yra žmogus sprendimų grandinėje. DI siūlo, įspėja, sudėlioja arba paaiškina. Žmogus patvirtina, atmeta arba prideda kontekstą.

Be šio žingsnio DI klaida automatiškai virsta veiksmu, ir būtent tai yra brangiausias scenarijus: užblokuota vadovo paskyra ketvirčio uždarymo dieną arba įspėjimas, kurį įrankis pats priskyrė triukšmui ir kurio niekas nebepatikrino.

Apibendrinimas

DI gynyboje užims vis daugiau vietos: atsijos fišingą, pastebės nuokrypius, sudės incidentų eigą, ras klaidų kode ir padarys mokymus gyvesnius.

Tai ne stebuklingas skydas. Tai stiprintuvas. Geras saugumo procesas su juo tampa greitesnis ir geresnis. Chaosas su juo lygiai taip pat sėkmingai tampa tik greitesnis.

Lietuvos atveju prisideda vietinė pastaba: kalbos barjeras, kuris metų metus dirbo čionykščių organizacijų naudai, dingo, o techniniai požymiai ir žmonių budrumas – ne. Būtent jais ir verta remtis.

Išvada trumpa: naudokite DI, bet neleiskite jam spręsti vienam. Tai pagalbininkas, o ne autopilotas.

DI kaip gynyba – dažniausiai užduodami klausimai

Susijusios Haxoris paslaugos: AI ir LLM integracijų įsilaužimų testavimas