Parasti jaunus mākslīgā intelekta modeļus vērtējam pēc ātruma, precizitātes un spējas uzrakstīt kvalitatīvu kodu. Taču tieši šīs priekšrocības kiberdrošības kontekstā var kļūt par riska faktoru.
Šis raksts tapis, lai paskaidrotu, kāpēc jaudīgs MI programmēšanā nav tikai produktivitātes rīks un ko no šāda gadījuma var mācīties ikviens, kas ikdienā izmanto datorus, kodu vai mākoņpakalpojumus.
Kad MI kļūst par uzbrucēju
Robeža starp aizsardzības automatizāciju un uzbrukuma automatizāciju ir ļoti šaura. To labi parāda situācija, kurā modeļa spējas tiek vērtētas ne tikai pēc lietderības, bet arī pēc iespējamā ļaunprātīgas izmantošanas scenārija.
Astra signāls nozarei
OpenAI apturēja Astra izstrādi drošības apsvērumu dēļ. Iekšējās pārbaudēs tika konstatēts, ka modelis ir ļoti spēcīgs programmēšanā un kiberdrošībā, tādēļ teorētiski varētu patstāvīgi identificēt ievainojamības un veikt kiberuzbrukumus.
Svarīgākais šajā gadījumā nav pats modeļa nosaukums vai tas, cik iespaidīgi tas spēj ģenerēt kodu. Būtiskākais ir pieņēmums, ka MI sistēma var apvienot vairākas prasmes vienā darbplūsmā:
- analizēt kodu, konfigurācijas vai publiski pieejamu tehnisko informāciju;
- atrast potenciāli kļūdainu ievadi, novecojušu komponenti vai nepareizu piekļuves konfigurāciju;
- sagatavot tehnisku darbību secību;
- pielāgot nākamo soli iepriekšējā rezultātam.
Atsevišķi šie uzdevumi nav jauni. Drošības speciālisti tos dara manuāli, izmantojot skenerus, logu analīzi, testēšanas vidi un savas zināšanas. Risks pieaug brīdī, kad viens rīks spēj samazināt laiku starp informācijas apkopošanu, ievainojamības atrašanu un darbības plāna izveidi.
Programmēšanas spējas maina risku
Koda ģenerēšana pati par sevi nav bīstama. Tā var palīdzēt izveidot skriptus, automatizēt rutīnas uzdevumus, pārskatīt konfigurācijas un ātrāk novērst kļūdas. Tomēr kiberdrošībā katrai tehniskai zināšanai ir divējāds pielietojums.
Piemēram, spēja analizēt tīmekļa lietotnes kļūdas var palīdzēt izstrādātājam atrast nedrošu autentifikācijas plūsmu. Tā pati spēja var tikt izmantota, lai mērķētu uz nepietiekami aizsargātu sistēmu. Līdzīgi ir ar tīkla konfigurācijām, piekļuves tiesībām, API atslēgām un programmatūras atjauninājumiem.
Tādēļ MI risku nevar vērtēt tikai pēc tā, vai modelis sniedz pareizu atbildi. Jāvērtē arī:
- cik autonomi tas var izpildīt uzdevumu ķēdi;
- cik labi tas spēj pielāgoties neveiksmīgam rezultātam;
- kādi rīki un dati tam ir pieejami;
- vai tā darbības tiek reģistrētas un pārraudzītas;
- vai cilvēks apstiprina kritiskos soļus.
Tieši autonomija ir būtiska. Čatbotam, kas izskaidro ievainojamības principu, un aģentam, kas spēj iteratīvi analizēt sistēmu un veikt darbības, ir atšķirīgs riska profils.
Drošība pirms pieejamības
OpenAI plāno ieviest papildu drošības pasākumus un turpināt Astra testēšanu kopā ar valsts iestādēm un MI drošības ekspertiem, pirms modeli piedāvāt lietotājiem. Šāda pieeja ir tehniski pamatota, jo sistēmām ar augstu ietekmi ar parastu funkcionalitātes testu nepietiek.
Drošības pārbaudēs jāskatās ne tikai uz to, ko modelis dara paredzētā scenārijā. Jāpārbauda arī robežgadījumi, proti, kā tas reaģē uz neskaidriem uzdevumiem, kā izmanto pieejamos rīkus, vai spēj apiet ierobežojumus un vai tā darbības var apturēt.
Tas ir atgādinājums, ka ātrāk palaist produktu nav vienīgais kvalitātes kritērijs. MI drošībā svarīga ir kontrolējamība.
MI rīku lietošanas robežas
Ikdienas lietotājam nav jāatsakās no MI palīgiem, taču tos nevajadzētu uztvert kā nekļūdīgus sistēmu administratorus vai drošības ekspertus. Īpaši uzmanīgi jāizturas pret rīkiem, kuriem piešķirta piekļuve failiem, e-pastam, kodu repozitorijiem, serveriem vai uzņēmuma mākoņvidei.
Pirms piešķirt MI rīkam piekļuvi, noskaidrojiet:
- kādi dati tam būs redzami;
- vai tas var veikt darbības vai tikai sniegt ieteikumus;
- vai piekļuves tiesības iespējams ierobežot;
- vai darbības tiek reģistrētas auditācijas žurnālos;
- vai kritiskām izmaiņām nepieciešams cilvēka apstiprinājums.
Drošāks sākumpunkts ir read-only piekļuve. MI var analizēt konfigurāciju vai sagatavot ieteikumus, bet produkcijas izmaiņas ievieš cilvēks pēc pārbaudes.
Praktiska drošības higiēna
MI attīstība neatceļ klasiskos drošības pamatus. Gluži pretēji, ja uzbrukumu sagatavošana kļūst ātrāka, novecojušas sistēmas un vāja piekļuves kontrole kļūst vēl riskantākas.
Ieviesiet šādas minimālās prakses:
- Atjauniniet programmatūru. Operētājsistēmas, pārlūkprogrammas, maršrutētāji un spraudņi jāatjaunina regulāri.
- Izmantojiet daudzfaktoru autentifikāciju. Parole viena pati nav pietiekama piekļuves aizsardzība.
- Atdaliet piekļuves līmeņus. Ikdienas darbam nevajag administratora tiesības.
- Pārskatiet koplietotos kontus. Katram lietotājam jābūt savam kontam un saprotamām tiesībām.
- Nodrošiniet rezerves kopijas. Datu atjaunošanas plāns ir tikpat svarīgs kā aizsardzība pret incidentu.
- Neievietojiet sensitīvus datus čatā. API atslēgas, paroles, klientu dati un iekšējās konfigurācijas nav piemērots ievads publiskam MI rīkam.
Risku domāšana ikdienā
Astra gadījums parāda, ka jaudīgāks MI nenozīmē tikai labāku asistentu. Tas nozīmē arī lielāku atbildību par piekļuves tiesībām, datiem un automatizācijas robežām.
Izmantojiet MI, lai ātrāk saprastu tehniskas problēmas, pārskatītu kodu un automatizētu drošas rutīnas. Taču kritiskās sistēmās saglabājiet cilvēka kontroli, minimālas piekļuves principu un pārskatāmu auditācijas pēdu. Jo gudrāks kļūst rīks, jo svarīgāk ir precīzi definēt, ko tam drīkst uzticēt.