Ģeneratīvā MI izmantošana kiberdrošībā: ko modelis analītiķa vietā izdara

Galvenais īsumā

  • Pētījumā valodas modelis pārņēma datu pārlasīšanu, bet lēmums abos uzdevumos palika analītiķim
  • Mērījām divās vietās: Android lietotņu pirmkodā un tīkla drošības žurnālos
  • Ātrums pieauga jūtami, taču kļūdaini pozitīvie konstatējumi nekur nepazuda un tos izsijāja cilvēks
  • Stipri aizsegtos un vairāku soļu uzbrukumos modelis apstājās
  • Rēķins aug līdz ar ievades apjomu, tāpēc žurnālus ir vērts izsijāt pirms modeļa, nevis pēc tā
  • Publiskā rīkā iekopēts žurnāla fragments ar IP adresēm un lietotājvārdiem ir personas datu apstrāde
  • MI rīka ziņojums neaizstāj ikgadējo IKT drošības pārbaudi, ko prasa Nacionālās kiberdrošības likums

Kiberdrošības analītiķa darbdiena lielākoties paiet, lasot datus: notikumu žurnālus, sistēmu konfigurācijas, ievainojamību ziņojumus, ļaunatūras analīzes. Rīki šos datus savāc un sagatavo, bet spriedumu par to, kurš brīdinājums nozīmē īstu uzbrukumu un cik liels risks aiz tā stāv, joprojām izdara cilvēks. Pētījumā Using Generative AI Models to Support Cybersecurity Analysts pārbaudījām, cik lielu daļu no šī darba spēj pārņemt ģeneratīvais MI, proti, valodas modelis (LLM), un kur tas kļūdās. Mērījām divos konkrētos uzdevumos: Android lietotņu pirmkodā un tīkla drošības žurnālos. Par to, kur mākslīgais intelekts aizsardzībā noder plašāk, rakstīts atsevišķi rakstā par MI kā aizsardzību; šeit seko viena pētījuma rezultāts.

Kāpēc ģeneratīvais MI drošības komandā vispār parādījās

Datu apjoms auga ātrāk nekā komandas. Vidēja uzņēmuma tīklā vienā diennaktī uzkrājas vairāk notikumu ierakstu, nekā komanda spēj izlasīt, un lielākā daļa no tiem ir nesvarīgi. Klasiskie rīki tos savāc, normalizē un sakārto, taču pēdējais solis paliek nemainīgs: kāds izlasa, salīdzina un izlemj. Tieši šis solis aizņem stundas.

Ģeneratīvais MI iestājas tieši šeit, un praksē tas dara četras lietas:

  • pārlasa drošības žurnālus un ātrāk izceļ novirzes,
  • ātrāk atrod lietotnēs izmantojamas kļūdas,
  • ielaušanās testā izspēlē, kuru kļūdu ar ko var savienot,
  • sakārto konstatējumus pēc atzītiem ietvariem, piemēram, OWASP Mobile Top 10 saraksta un MITRE ATT&CK.

Kopīgais visiem četriem uzdevumiem ir viens: no liela datu apjoma izcelt to nelielo daļu, kurai ir nozīme. Tur, kur nav ko izcelt, modelis neko nepievieno.

Divi izmēģinājumi no pētījuma

Izvēlējāmies divus uzdevumus, ar kuriem drošības komanda strādā tāpat katru dienu.

1. Ievainojamības Android lietotnēs

Uzbūvējām sistēmu, kas divu labi zināmu rīku – MobSF (Mobile Security Framework) un Semgrep – izvadi savieno ar valodas modeli. Statiskā analīze redz paraugu, bet ne koda nolūku: tā atzīmē izsaukumu, nevis atbild uz jautājumu, vai konkrētajā lietotnē tas tiešām ir bīstams. Tāpēc blakus statiskajai analīzei nostādījām konteksta analīzi, kuras uzdevums bija:

  • izlasīt lietotnes pirmkodu,
  • atpazīt drošības kļūdas pēc iepriekš uzrakstītiem noteikumiem,
  • sakārtot konstatējumus pēc OWASP Mobile Top 10 saraksta.

💡 Galvenais rezultāts: modelis kļūdas atrada ātrāk un precīzāk nekā rīki paši par sevi, taču deva arī kļūdaini pozitīvus konstatējumus (angliski false positive), un tos izsijāt varēja tikai cilvēks.

2. Drošības žurnālu analīze incidentu atklāšanai

Otrais uzdevums bija tīkla drošības žurnāli: Suricata (IDS/IPS) izvade un Windows procesus uzraugošā Sysmon ieraksti. Modelim prasījām sasaistīt brīdinājumus ar īstiem uzbrukumiem, atmest kļūdaini pozitīvos un katram incidentam piekārtot atbilstošo MITRE ATT&CK paņēmienu.

💡 Galvenais rezultāts: laiks līdz brīdim, kad kļuva skaidrs, kas notiek un cik tas ir nopietni, saruka ievērojami. Stipri aizsegtos un vairākos soļos izpildītos uzbrukumos modelis savukārt apstājās.

Ko modelis paveic un ko ne

UzdevumsKo modelis paveicKas paliek analītiķim
Žurnālu izsijāšanaIzlasa tūkstošiem rindu un atzīmē tās, kuras izceļas no ierastāZināt, kas šajā tīklā ir normāla darba diena, un atmest to, kas tikai izskatās neparasti
Pirmkoda caurskateAtrod zināmus kļūdu paraugus un paskaidro, kāpēc vieta ir bīstamaPārbaudīt, vai kļūda konkrētajā lietotnē tiešām ir izmantojama
Konstatējumu sakārtošanaPiekārto kategoriju pēc OWASP Mobile Top 10 vai MITRE ATT&CKIzlemt, kurš konstatējums ir pirmais novēršanas rindā
Incidenta aprakstsSaliek notikumu secību saprotamā tekstāApstiprināt, ka secība atbilst tam, kas tiešām notika
Riska lēmumsNekoVisu: sistēmas nozīmi, datu kategoriju, sekas darbībai

Tabulas pēdējā rinda ir svarīgākā. Modelis ir ātrs lasītājs, nevis atbildīga persona. Tas, ka sistēma ir kritiska, ka konkrēti dati ir personas dati un ka pakalpojuma apstāšanās maksā konkrētu naudu, ir organizācijas konteksts, kura modelim nav.

Kur šī pieeja maksā vairāk, nekā izskatās

Pētījums parādīja arī robežas, un tās ir vērts nosaukt vārdā.

  • Kļūdaini pozitīvie konstatējumi. Modelis var pārprast gan žurnāla rindu, gan koda fragmentu un paziņot par draudiem, kuru nav. Tas nav novēršams ar labāku uzvedni; tā ir metodes cena.
  • Izmaksas. Liela datu apjoma apstrāde ar valodas modeli ir dārga, un rēķins aug līdz ar ievades apjomu. Praksē tas nozīmē, ka žurnālus izsijā pirms modeļa: filtrē, apkopo un ieliek kontekstā tikai to, kas patiešām jāizlasa.
  • Paša risinājuma drošība. Analīze ar MI ienes jautājumus par datu konfidencialitāti, bet arī pats modelis kļūst par uzbrukuma mērķi. Ko tieši šādā uzstādījumā pārbauda, apkopots rakstā par LLM integrāciju ielaušanās testēšanu.

Trešais punkts nav teorētisks. Pēc Kroll apkopojuma 92% MI sistēmu ielaušanās testu atklāja, ka pārbaudītais modelis ir ievainojams pret kādu prompt injection formu. Ja rīks, ar kuru izsijā incidentus, pats izpilda svešu norādījumu no apstrādātā satura, tad ātrums ir iegūts uz uzticamības rēķina.

Ko tas nozīmē Latvijas organizācijai

Pirmais jautājums ir par datiem. Iekopēts žurnāla fragments ar IP adresēm, lietotājvārdiem un e-pasta adresēm ir personas datu apstrāde Vispārīgās datu aizsardzības regulas (VDAR) izpratnē, un tai vajadzīgs tiesiskais pamats, skaidrs glabāšanas termiņš un atbilde uz jautājumu par nodošanu ārpus Eiropas Ekonomikas zonas. Uzraudzības iestāde Latvijā ir Datu valsts inspekcija. Praktiskais secinājums ir vienkāršs: publisks tērzēšanas rīks nav vieta, kur ielīmēt incidenta materiālus, bet identifikatorus pirms analīzes ir vērts aizstāt.

Otrais jautājums ir par pierādījumiem. Nacionālās kiberdrošības likuma (turpmāk – NKDL) 25. panta piektās daļas 2. punkts uzliek kiberdrošības pārvaldniekam pienākumu ne retāk kā reizi gadā veikt informācijas un komunikācijas tehnoloģiju drošības pārbaudi un atbilstoši tās rezultātiem organizēt konstatēto trūkumu novēršanu. Ministru kabineta noteikumu Nr. 397 „Minimālās kiberdrošības prasības“ 131. punkts A klases informācijas sistēmai prasa ielaušanās testu pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados. MI rīka izvade šo pienākumu neizpilda: pārbaudei vajadzīgs saskaņots tvērums, datumi, pārbaudīti konstatējumi un pierādāma novēršana. Uz ko un cik bieži šis pienākums attiecas, apskatīts rakstā par to, vai ielaušanās testēšana ir obligāta.

Trešais jautājums ir par caurskatāmību. Eiropas Parlamenta un Padomes regulas (ES) 2024/1689 jeb MI akta 50. pants, ko piemēro no 2026. gada 2. augusta, prasa, lai cilvēks zinātu, ka sarunājas ar MI sistēmu, un lai mākslīgi radīts saturs būtu marķēts. Iekšēju analītiķa rīku tas skar maz, taču brīdī, kad tas pats modelis atbild klientam, prasība sāk darboties.

Vienu lietu ir vērts pateikt uzreiz. HAXORIS ir Slovākijas uzņēmums, un NKDL 44. pantā noteikto atbilstības auditu neveicam; to veic neatkarīgs kiberdrošības auditors. Strādājam tehniskajā pusē: testējam sistēmas un sagatavojam ziņojumu, kuru auditors var pārbaudīt. Kā šī procedūra norit un kas tajā ko dara, aprakstīts rakstā par kiberdrošības auditu.

Kā MI iekļaut drošības darbā, nezaudējot kontroli

Pētījuma praktiskā daļa noslēdzas ar sešiem soļiem, kurus var izdarīt jebkura komanda.

  • Sāciet ar uzdevumiem, kuriem ir pārbaudāma atbilde. Žurnāla rindas skaidrojums, koda fragmenta apraksts, incidenta kopsavilkums: visos trijos gadījumos rezultātu var salīdzināt ar avotu dažās minūtēs.
  • Izsijājiet ievadi pirms modeļa. Vispirms filtrs un apkopojums, tikai pēc tam modelis. Tas vienlaikus samazina rēķinu un kļūdaini pozitīvo konstatējumu skaitu.
  • Katram konstatējumam prasiet pierādījumu. Žurnāla rindu, faila nosaukumu, koda vietu. Apgalvojums bez atsauces uz avotu nav konstatējums, bet pieņēmums.
  • Neievadiet jutīgus datus publiskā rīkā. Aizstājiet identifikatorus un izvēlieties vidi, kurā ievade nenonāk modeļa apmācībā.
  • Pierakstiet, ko modelis ierosināja, nevis tikai to, ka tas atbildēja. Bez šīs pēdas vēlāk nevar pateikt, kāpēc brīdinājums tika noraidīts.
  • Pārbaudiet pašu risinājumu. Tiklīdz modelis saņem piekļuvi datiem un tiesības izsaukt rīkus, tas ir jauna uzbrukuma virsma; šo daļu nosedz MI un LLM integrāciju ielaušanās testēšana, nevis parasta lietotnes caurskate.

Septītais solis nav tehnisks. Vienojieties komandā, kas ir modeļa uzdevums un kas nav. Ja analītiķis rīku uztver kā otru pāri acu, tas palīdz; ja kā tiesnesi, agrāk vai vēlāk kāds paraksta lēmumu, kuru nav pārbaudījis.

Kurp tas viss virzās

Neraugoties uz ierobežojumiem, joma attīstās ātri. Konkrētam uzdevumam pieskaņoti modeļi, drošības vajadzībām būvēti pašu modeļi un reāllaikā pielāgojama mācīšanās var mainīt to, cik ātri uzbrukumu pamana, saprot un aptur. Tomēr virziens, kuru pētījums iezīmēja, paliek tas pats: mainās nevis atbildība, bet ātrums, ar kādu analītiķis nonāk pie faktiem.

Atšķirība starp komandu, kurai MI palīdz, un komandu, kurai tas kaitē, nav modeļa izvēlē. Tā ir procesā: vai konstatējumu kāds pārbauda, vai ievade ir izsijāta un vai kāds paliek atbildīgs par lēmumu.

Kopsavilkums

Modelis izlasīja vairāk nekā cilvēks un ātrāk nekā cilvēks. Precīzāku to nepadarīja: kļūdaini pozitīvie konstatējumi palika, sarežģītos uzbrukumos tas apstājās, bet apstrādes izmaksas auga līdz ar datu apjomu. Tāpēc darba dalījums iznāca pretējs tirgus solījumiem par autonomu aizsardzību: datus pārcilā mašīna, secinājumu izdara analītiķis.

HAXORIS šajā jomā strādā tehniskajā pusē. Veicam MI un LLM integrāciju ielaušanās testēšanu, mobilo lietotņu ielaušanās testēšanu un ievainojamību novērtēšanu atbilstoši OWASP metodoloģijai, bet gatavību NKDL un NIS2 prasībām novērtējam atsevišķi, kā aprakstīts NIS2 ielaušanās testēšanas lapā. Ja MI funkcijas jau darbojas produkcijā vai tuvojas palaišanai, piesakieties bezmaksas konsultācijai, un kopā ar jūsu komandu saskaņosim tvērumu.

Visu pētījuma rezultātu apraksts publicēts zinātniskajā rakstā:

Zinātniskā publikācija

Jo vairāk MI rīku nonāk drošības komandas rokās, jo vairāk nozīmes iegūst darba dalījums: datus pārcilā mašīna, lēmumu pieņem cilvēks. No tā arī ir atkarīgs, cik ātri un cik precīzi aizsardzība nostrādā.

🔐 Modrība, aktuālas zināšanas un MI ar aprēķinu – tieši šādā secībā.

Ģeneratīvais MI kiberdrošībā – biežāk uzdotie jautājumi

01

Vai valodas modelis aizstāj drošības analītiķi?

Nē. Pētījumā modelis paātrināja datu pārlasīšanu: izgāja cauri žurnāliem un pirmkodam un atzīmēja to, kas pelna uzmanību. Lēmums abos uzdevumos palika cilvēkam, jo modelis deva arī kļūdaini pozitīvus konstatējumus un stipri aizsegtos vai vairāku soļu uzbrukumos apstājās. Darba dalījums iznāk pretējs ierastajam priekšstatam: datus pārcilā mašīna, secinājumu izdara analītiķis.

02

Kāpēc modelis dod kļūdaini pozitīvus konstatējumus?

Tāpēc, ka arī žurnāla rindu un koda fragmentu tas lasa kā tekstu un secina pēc līdzības. Ja raksts atgādina īsta uzbrukuma rakstu, modelis paziņo arī tad, kad nekas nav noticis. Tā nav sistēmas kļūda, bet metodes cena: katrs konstatējums ir jāpārbauda, un procesu ir vērts uzbūvēt tā, lai pārbaude būtu ātra.

03

Uz kādiem ietvariem pētījums balstījās?

Uz diviem. Android lietotņu pārbaudē konstatējumus sakārtojām pēc OWASP Mobile Top 10 saraksta, bet žurnālu analīzē incidentus piekārtojām MITRE ATT&CK ietvara paņēmieniem. Rīku pusē strādājām ar MobSF un Semgrep izvadi, kā arī ar Suricata un Sysmon ierakstiem.

04

Vai MI rīka ziņojums aizstāj ikgadējo IKT drošības pārbaudi?

Nē. Nacionālās kiberdrošības likuma 25. panta piektās daļas 2. punkts uzliek kiberdrošības pārvaldniekam pienākumu ne retāk kā reizi gadā veikt informācijas un komunikācijas tehnoloģiju drošības pārbaudi un atbilstoši tās rezultātiem organizēt konstatēto trūkumu novēršanu. Pārbaudei vajadzīgs saskaņots tvērums, datumi, pārbaudīti konstatējumi un pierādāma novēršana. MI rīks ir ikdienas darba slānis, nevis pierādījums.

05

Vai sistēma, kurā darbojas MI, jāpārbauda atsevišķi?

Jā. Ap valodas modeli uzbūvētā lietotne blakus parastajām tīmekļa un API kļūdām iegūst savu uzbrukuma virsmu: prompt injection, datu avotu uzticamība, modeļa piekļuves tiesības un tas, kas ar atbildi notiek tālāk. Šo daļu pārbauda atsevišķā testēšanas lokā, jo klasisks lietotnes tests ķēdi no uzvednes līdz rīkam nenosedz.

06

Kādus datus drīkst ievadīt publiskā MI rīkā?

Pēc noklusējuma nekādus klientu, darbinieku vai incidenta datus. Iekopēts žurnāla fragments ar IP adresēm, lietotājvārdiem un e-pasta adresēm ir personas datu apstrāde Vispārīgās datu aizsardzības regulas izpratnē, ar jautājumiem par tiesisko pamatu, nodošanu ārpus Eiropas Ekonomikas zonas un glabāšanas termiņu; uzraudzības iestāde Latvijā ir Datu valsts inspekcija. Drošākais ceļš ir izmantot vidi, kurā ievade nenonāk modeļa apmācībā, un pirms tam aizstāt identifikatorus.

Pārbaudīsim, ko no jūsu MI asistenta var izvilkt, pirms to izdara kāds cits.

Pieteikties bezmaksas konsultācijai