Veiksmingas gaujų laiškų detekcijos AI agentų vadovas: 2026 įmonių pasirinkimo ir diegimo analizė
Nuo SPF/DKIM/DMARC iki didelio modelio semantinės analizės, gilus AI varomų gaujų laiškų variklių derinimas, kaip jie įgyvendinami realioje grėsmės aplinkoje
Daniel Nikulshyn
Editor
Grėsmių panorama
Kodėl phisingas vis dar yra 2026 m. pagrindinė atakų krypčia
Nors el. pašto saugumo pramonė jau pažengusi daugiau nei dvi dešimtis metų, phisingas (phishing) vis dar yra pagrindinė įmonių duomenų nutekio įlanka. Remiantis daug metų leidžiamu Verizon „Duomenų nutekio tyrimo“ (DBIR) ataskaita, socialinė inžinerija bei kredencijalų vagystė pastaraisiais metais visada buvo tarp pagrindinių vietų duomenų nutekio atvejuose, o el. paštas yra dažniausias tokių atakų kanalo tipo. Vikipedijos phisingo apibrėžimas paaiškina, jog jo esmė – atakuotojai maskuojasi kaip patikimi asmenys, kūrėjai, kad aukos atiduotų savo kredencijalus, pavedimus ar įdiegtų kenksmingą programinę įrangą. Nuo 2022 m. generavimo AI plitimas žymiai sumažino phisingo turinio kūrimo kaštus. Ankstesnis, remiantis klaidų rašyme ir blogu sintaksiniu supratimu, kad phisingo el. laiškus pažintų, patyrimas jau nebeveikia – didieji kalbos modeliai gali sugeneruoti gramatiškai visiškai teisingus, su įmonės kultūra derinantis, gundymo tekstus, net ir gali pagal aukos viešai prieinamus socialinius duomenis kurptyniškus turinio variantus, tai yra vadinamąjį „harpuninį“ phisingą (spear phishing) ir verslo el. pašto sukčiaavimą (BEC, Business Email Compromise). Ypač reikėtų atidžiai stebėtis BEC. FBI interneto nusikaltimų skundų centro (IC3) ataskaitose daug metų jau BEC yra laikoma viena didžiausių finansinių nuostolių sukėlusių interneto nusikaltimų, šios atakos dažnai neturi jokių blogų jungčių ar priedų, o tiesiog remiasi socialine inžinerija ir manipuliuoja finansininkais, kad jie peraduotų lėšas, o tai visiškai priverčia tradicinius, pagrįstus parašais bei juodojo sąrašo URL aiškino, detekcijos priemones. Būtent dėl tokių „be krovinio“ atakų atsiradimo, AI kalbos supratimo detekcijos agentai iškyla į pirmąją liniją. Jie nebematuoja tik jungčių bei priedų, o analitškai nagrinėja ketinimus, ryšio nepakankamumus ir kalbos schematas, o tai sudaro techninę šio gidų aprašomąją dalį.
- Phishing - Wikipedia — Vikipedijos apibrėžimas apie phisingo atakų tipus ir istoriją
- FBI IC3 metinė ataskaita — FBI interneto nusikaltimų skundų centro leidžiamos BEC ir kitų nuostolių statistikos
Techninė bazė
Patikrinimo protokolas yra pamatas, bet toli gražu ne visa
Bet kokia rimta fišinginių laiškų detekcijos schemos sudarytos iš trijų pagrindinių pašto patikrinimo protokolų: SPF, DKIM ir DMARC. SPF (Sender Policy Framework) naudojant DNS įrašus nusako, kurie serveriai gali atstovauti konkrečiam domenui siunčiant laiškus; DKIM (DomainKeys Identified Mail) naudoja šifruotą parašą, kad patikrintų, ar laiškai perduodant nebuvo pakeisti; DMARC (Domain-based Message Authentication, Reporting and Conformance) nusako patikrinimo nesėkmės atveju tvarkymo strategiją (nieko, karantinas, atmetimas) ir teikia sueigtus ataskaitos duomenis. Vikipedijos DMARC straipsnis paaiškina, kad jo svarbiausias indėlis yra 'suderinimas' - užtikrinant, kad SPF/DKIM patikros domenas ir naudotojų iš tiesų matomas From domenas sutampa, siekiant užkirsti kelią domeno kopijavimui. Google ir Yahoo 2024 m. pradėjo reikalauti DMARC didelėms siuntėjų gretims, ir šis industrijos žingsnis stipriai susiaurino tiesioginio domeno klastojimo erdvę. Vis dėlto, šie protokolai gali išspręsti tik 'kas turi teisę naudoti šį domeną siunčiant laiškus' klausimą. Jie nieko negali prieš du kategorijas aukšto riziko atakas: pirmoji, kuomet puolėjai registruoja domeną, kuris yra labai panašus į tikrojo (pvz., naudodami rn, kad panašu į m), ir toks laiškų siuntėjas gali patenkinti savo domeno DMARC patikrą; antroji, kuomet puolėjai įsiveržia į teisėtų partnerių teisėtus pašto dėžutes ir pradeda atakas, kuomet visos patikros yra sėkmingos. Čia ir pasireiški AI detekcijos agentai. Jie naudoja patikros rezultatus kaip vieną iš daugelio bruožų, o ne kaip vienintelį teismo sprendimą, ir dar sudeda siuntėjo elgesio piešinį, semantinį sąmoningo analizinį ir ryšio grafą, kad galėtų dengti patikros protokolų aklovižčio zoną. Suprantant šį darbo pasidalijimą, galėsite išvengti klaidų, sukeltų tokiais žodžiais kaip 'mes palaikome DMARC', vertinant bet kurį tiekėją.
- DMARC - Vikipedija — DMARC protokolo veikimo principas, sutapimo mechanizmas ir strategijų tipai
- DKIM - Vikipedija — DKIM šifruoto parašo patikros techniniai detalės
Variklio vidus
AI detekcijos agentų šerdis: techninės kompetencijos
Šiuolaikiniai AI šmingojo el. pašto detekcijos agentai paprastai sudaryti iš keturių gebėjimų sluoksnių. Pirmasis sluoksnis – tradicinė deterministinė detekcija: URL reputacijos duomenų bazė, priedų smėlio dėžės sprogimai, priedų hash vertinimas – ši techninė dalis yra pakankamai sudėtinga, pagrindinė jos paskirtis – sulaikyti žinomas grasinimus. Antrasis sluoksnis – statistinė ir mašininio mokymo bruožų inžinerija, kuri išskiria šimtus signalų, pvz., siuntėjo domeno registravimo trukmė, pirmojo ryšio žymė, atsakymo adreso ir siuntėjo adreso nesusipratimai, sluoksniuose paslidę Unicode homoglifai ir t.t. Trečiasis sluoksnis yra pastarųjų metų svarbus proveržis – gamtinės kalbos procesai bei didžiųjų kalbos modelių varomių reikšmės ir analizė. Variklis nebe tik klauso, „Ar ši nuoroda yra saugi?“, bet ir „Ką šis laišką bandys mane įtikinti?“. Jis gali atpažinti spaudimą ir panūdijimą (pvz., „Prašau per 30 min. įvykdyti pavedimą“), autoriteto pasišaipymą (pvz., pasivadinėjant CEO), taip pat ir kalbos struktūros bei konstrukcijos nutukimus. OpenAI ir Anthropic gamintojų didžiųjų modelių API padidina šios analitikos tikslumą, tačiau taip pat sukelia naujus sąnaudas, užtrukas bei konflikthus dėl privatumo. Ketvirtasis sluoksnis yra sąsajų schemos ir elgesio tipai. Agentas analizuoja organizacijos vidaus ir išorės komunikacijos istoriją ir kuria kiekvieno siuntėjo „normalaus elgesio portretą“: paprastai kada siunčia laiškus, kokia įranga naudojama, su kuo bendraujama, įprastas kalba. Kai laiškas nukrypsta nuo tipiško elgesio (pvz., CFO staiga reikalauja skubą peržiūrėti pavedimą iš nežinomo IP adreso ankstyvu rytu), sistema suteikia aukštą rizikingumo įvertinimą. Šis nepriklausantis nuo žymesnių nulių dienų BEC atakų aptikimo metodas yra labai efektyvus, nes jo veikimui nereikia jokių žinomų ženklų. Kūrėjai, vertinant teikėjus, turėtų pasiteirauti, ar semantinė analizė yra taisyklių šablonas ar tikrai modelių logika? Elgesio tipams reikia kokio mokymo laiko? Kaip neteisingi pranešimai pateikiami į modelį? Šių klausimų atsakymai daug geriau atskleis produkto tikrąją lygį, negu paprastas teigimas, kad „naudojamas AI“.
- OpenAI platformos dokumentacija — Oficiali didžiųjų modelių API dokumentacija skirta semantinės analizės tikslumui
- Anti-phishing software - Wikipedia — Prieš šmingąjį el. pašto programinės įrangos techninės klasifikacijos ir aptikimo metodų apžvalga
Architektūros sprendimai
Šliuzo lygio vs API lygio: dvi įgyvendinimo architektūros alternatyvos
Pasirinkimo metu esminis architektūrinis nesutarimai yra tuo, kur yra detekcijos taškas. Tradicinės saugaus el. pašto šliuzas (SEG, Secure Email Gateway) įdiegiamas el. pašto srauto įėjime, pakeičiant MX įrašus, kad visi įeinantys el. laiškas būtų nukreipti į detekcijos paslaugą, o paskui pateiktas į pašto dėžutę. Šis būdas visiškai efektyvus, nepriklausantis nuo el. pašto platformos API, tačiau trūkumas yra tai, kad negali matyti jau pateiktų el. laiško vėlesnių pokyčių (kaip vėluojančių aktyvavimo nuorodų), taip pat sunku analizuoti vidinius horizontaluosius žvejybą. Pastaruoju metu populiarėja API lygio integrai (dažnai vadinami ICES, Integrated Cloud Email Security). Jis per Microsoft Graph ar Google Workspace API tiesiogiai skaito el. pašto dėžutes, atlieka vidinę ar vėlesnę el. laiško skanavimą. Pranašumas yra tai, kad įdiegimas užtrunka keli minutes, nereikia keisti MX įrašų, galima matyti vidinius el. laiškus ir palaikyti el. laiško atšaukimo funkciją (claw-back). Microsoft Defender for Office 365 ir Google Workspace natyvoji sauga yra šios minties atstovai. Abi architektūros nėra viena kitos atmestinos. Daugeliui subrendusių organizacijų naudojamas 'šliuzas kaip grubus filtravimas + API lygis kaip smulkus tikrinimas' gilusis gynimosi būdas. Specialistai turėtų sversti: šliuzo schemos atidėliui jautrios situacijose yra daugiau kontrolės, tačiau priežiūra yra sunkesnė; API schemos įdiegimas yra lengvesnis, matomumas yra stipresnis, tačiau jai ribojama platformos API tempu ir teisėmis, o vėlesnis atšaukimas reiškia, kad kenksmingas el. laiškas trumpai buvo laikinai saugomas vartotojo pašto dėžutėje. Vienas dažnai nenustatytas įvertinimo punktas yra duomenų saugojimas ir privatumas. API lygio schemai reikia leidimo trečiosioms šalims skaityti viso el. laiško turinio, kas yra didelis sprendimas įmonėms, kurios yra pagal GDPR ar pramonės atitikties reikalavimus. Būtina patikrinti, kur tiekėjo duomenys yra apdoroti, koks jų laikymo laikas ir ar el. laiško turinys yra naudojamas bendrojo modelio mokymui.
- Microsoft Defender for Office 365 — Oficiali Microsoft el. pašto grėsmių apsaugos dokumentacija
- Email filtering - Wikipedia — El. laiško filtras ir saugos šliuzo techninė prielaida
Pasirinkimo metodologija
Vertinimo struktūra: ką turėtų matyti ir kaip matyti
Beveik kiekvienas tiekėjas rinkoje tvirtina, kad jų „atpažinimo koeficientas yra 99% ir daugiau“, bet šis skaičius be testų rinkinio neturi jokio prasmės. Siūlau saugumo komandai sukurti vertinimo struktūrą, sudarytą iš keturių dalių: atpažinimo efektyvumas, klaidinguosios informacijos apkrova, priežiūros patirtis ir visiška savininko sąnauda. Atpažinimo efektyvume, svarbu neišskirti visuotinę tikslingumą, o skirti tipus: atpažinti blogai įtaka turinčius fisingo laiškų, atpažinti priedų tipo kenkėjus, atpažinti grynuosius tekstus BEC, atpažinti vidaus fisingo atvejus atskirai ir matuoti atkviesties koeficientą. Vertingiausias būdas – naudoti istorijoje nepastebėtus tikrus pavyzdžius (po to, kai buvo išvalyti) atlikus grįžtamajį testą, o ne tiekėjo pateiktus pavyzdžius. Be to, reikia pareikalauti bent 30 dienų lygiagrečio bandymo (shadow mode), kad naujas variklis negadina gamybos, o paskui palyginti su tikrojo rezultato palyginimu. Klaidinguosios informacijos sąnaudos yra labiausiai neištvertos sąnaudos. Klaidinguosios informacijos koeficientas, atrodo, kad yra tik 0,1%, bet tai reiškia, kad kasdien apdirbama šimtas tūkstančių laiškų, kasdien tūkstančiai normalių laiškų yra neteisingai izoliuoti, kas tiesiogiai gali suniokoti SOC ir įsilaužti į vartotojo pasitikėjimą sistema. Vertinimo metu turėtų būti įrašyti kiekvieno klaidingo pranešimo tvarkymo valandos darbas ir išbandyti tiekėjo informacijos grąžinimo ciklo efektų greitį. Priežiūros ir sąnaudų matas apima: strategijos konfigūracijos granulomėtros ir skaitymui, SIEM / SOAR integruotų gylį, įvykių tyrimo sąsajos naudingumą, ir kainos modelį (pagal pašto dėžutę, pagal pašto kiekinį ar pagal vietą). Slėptinos sąnaudos dažnai atsiranda profesinių paslaugų, derinimo ciklo ir reikalingos papildomos grėsmės žvalgybos prenumeratos srityje. Įrašydami viską į sprendimų lentelę, galima išvengti realaus TCO, kuris viršija biudžetą, atidengimo.
- Precision and recall - Wikipedia — Supratimas apie detekcijos sistemų tikslingumą ir atkviesties koeficientą
Puolimo ir gynybos žaidimas
Priešinga realybė: kai atakuoja tuo pačiu naudoja AI
Fishingo laiškų atpažinimas yra nuolatinės kovos žaidimas. Atakuojantys jau pradėjo naudoti apgaulingus būdus, kad apsieitų AI detektorių: įmonių laiškų viduje įterpia slaptus „pranešimo įstatymo“ (prompt injection) tekstus, bandydami manipuliuoti LLM bazės variklio analize; naudodami paveikslėlius tekstui pernešti, kad apeitų tekstų skenavimą; arba naudodami teisėtus debesų dokumentų dalijimo saitus (Google Docs, SharePoint), kad paversdintų blogą turinį tik po kelių peradresavimų. Vikipedijos straipsnis apie priešingą mašininio mokymosi (adversarial machine learning) teigia, kad bet kokia modelių priklausanti atpažinimo sistema yra pavojus, kai yra sudarytos priešingos pavyzdžiai. Tai reiškia, kad, jei tiekėjas remiasi vieninteliu dideliu modeliu, jis gali būti konkrečiais puolimais pažeidžiamas. Stabilus sprendimas turėtų būti daugiakompmentės struktūros, kurioje niekas vienas signalas negali vienas paskirti galutinio teismo. Kitas neigiamas faktas yra „atpažinimo lėtumas“. Kai sistema dažnai parodyti rizikingi pranešimai, vartotojai paprastai pradeda juos ignaruoti. Todėl geros prekės turėtų būti rizikingų laiškuose atliekamos klasifikacijos – tikrai aukšto rizikingumo laiškams turėtų būti parodyti stipri signalai, o žemų ir vidutinių rizikingumo laiškams – lengvi signalai, kad vartotojo dėmesį paskirtų į svarbiausias vietas. Tai yra produkto dizaino, o ne gryno techninio produkto, bet tiesiogiai nulemia apsaugos realaus poveikio efektyvumą. Galiausiai, technika negali pakeisti žmogaus mokymosi. Moderniausias AI agentas taip pat turėtų būti derinamas su kasdieniniais fisingo simuliacijų ir saugumo sąmonės mokymų su darbuotojais. AI agentą turėtų laikyti kaip „sumažinimo kiekiui blogų laiškų, pateikiančių konteksto sprendimų pagalbą“, o ne „visų fisingo eliminavimą“, kad tai atitikt realų tikėjimą.
- Adversarial machine learning - Wikipedia — Priešinga mašininio mokymosi grėsmė detekcijos sistemoms
- Anthropic saugumo tyrimai — Apie pranešimo įvedimo ir modelių saugumo tyrimus
Įgyvendinimo vadovas
Įgyvendinimo kelias: 90 dienų įdiegimo planas
Remiantis daugkartinės įdiegimo patirtimi, siūlau AI žvejybos el. laiškų agento įdiegimą suskirstyti į tris 30 dienų etapus. Pirmosios 30 dienų yra bazinė linija ir paralelinis bandymas: nebepakeičiant esamos el. laiškų srauto, naudojant shadow mode įjungiama nauja variklis, surinkti jo įvertinimai realiems el. laišksams, palyginant su esama būsena, kiekybiniu būdu nustatant naujus nusikaltimus ir klaidingus pranešimus. Be to, užbaigti SPF/DKIM/DMARC sveikatos patikrinimą, užtikrinant, kad patikrintų pagrindas yra tvirtas – daugelis organizacijų šioje stadijoje supranta, kad jų DMARC vis dar yra sustabdytas p=none. Antrasis 30 dienų yra pusiau atidarytos perjungimo ir strategijos optimizavimas. Pasirinkti kontroliuojamo rizikingo skyriaus (dažnai finansų ar aukšto rango pareigūnų komandos yra BEC aukšto rizikingumo grupė) pirmauja įgalinti priverstinių atkirtimų, glaudžiai stebėti klaidingus pranešimus ir įkurti greitą praleidimo kanalą. Šios stadijos pagrindinis rezultatas yra strategijos bazinė linija ir atnaujinimo procesas (playbook), aiškiai nusakantis, kokio lygio įspėjimai bus automatinių, kokie reikalauja SOC rankinio sprendimo. Trečiasis 30 dienų yra visiškas plėtimas ir operacinis sustiprinimas. Įjungti el. laiškų detekcijos agentą su SIEM/SOAR, realizuojant automatinį atšaukimą, automatinį izoliavimą ir事件 darbo lapo sąveiką; įkurti klaidingų pranešimų grąžinimo procesą, užtikrinant, kad kiekvienas netinkamai atkirstas el. laiškas galėtų greitai grįžti į modelį; be to, pradėti pirmąją žvejybos simuliacijos treniruotę, patikrinant žmogaus ir mašinos bendradarbiavimo tikrą saugumą. Nepamirškite išsaugoti atšokimo planą. Bet koks sistema, priklausanti nuo trečiųjų API ir modelių, gali laikinai neveikti dėl tiekėjo gedimo, modelių atnaujinimo arba greitį ribojimo, tad iš anksto sutartas mažinimo strategija (pvz., automatinis grąžinimas prie konservatyviosios taisyklingosios taisyklės) gali užkirsti kelią tiekėjo avarijai tapti visos organizacijos el. laiškų nutrūkimu. Įrašydami šiuos dalykus į sutarties SLA punktus, tai yra darbuotojų apsaugos paskutinė gynybinė linija.
- Security information and event management - Wikipedia — SIEM/SOAR ir el. laiškų detekcijos sistemos sąveikos sąlyginiai
Ištekliai
- Gaujų puolimas - Vikipedija
Gaujų puolimo apibrėžimas, tipai ir istorija
- DMARC - Vikipedija
Laiškų patikrinimo ir apgavystės prevencijos protokolas
- Microsoft Defender Ofis 365 dokumentacija
Oficiali Microsoft dokumentacija apie laiškų saugumo produktus
- OpenAI platformos dokumentacija
Didelių modelių API naudojimas semantinės analizės skirtoms
- Anthropic tyrimų puslapis
Tyrimai apie modelių saugumą ir valdymą
Dažniausiai užduodami klausimai
Ar AI gaujų detekcijos agentai gali visiškai pakeisti tradicinius saugaus laiškų vartus?
Paprastai ne. Jie paprastai naudojami kaip papildiniai. API lygio AI detekcija yra efektyvesnė BEC ir vidinių gaujų detekcijoje, tačiau vartai vis dar turi vertę įėjimo filtro ir užlaikymo valdyme.
Kokie yra diegant API lygio schemą, reikalingą visiems laiškams skaityti, teisės riskai?
Pagrindiniai klausimai – duomenų vietovė, laikymo trukmė ir ar ji naudojama mokymui. Įmonės, kurias reglamentuoja GDPR ar kitaip, turėtų patikrinti tiekėjo duomenų tvarkymo vietą, pasirašyti DPA sutartį ir aiškiai nurodyti, kad laiškų turinys nebus naudojamas mokymui.
Kodėl net jei yra DMARC, vis dar galima gauti gaujų laiškų?
DMARC gali prevenciškai veikti tik domeno klastojimą, bet neturi jokios įtakos panašioms domenų pavadinimams, kuriais naudojasi užpuolikai, bei įsigijimams partnerių el. pašto dėžučių, nes juos palaiko patvirtinimas.
Ar teigiamas 99 % detekcijos rodiklis patikimas?
Detekcijos dydis be testo rinkinio nereikšmingas. Reikia skirti tipų atpažinimo rodiklį ir naudoti paties savo istorijos neišduotų pavyzdžių atidarymo bandymą, taip pat atlikti bent 30 dienų paralelinio bandymo patikrinimą.
Kiek didelis yra netikrų signalų veikimo našumas?
Lengvai neprireikšmingas. Net 0,1 % netikrų signalų rodiklis, milijoninėse el. laiškų apimtyse, reiškia, kad kasdien šimtai įprastinių laiškų yra sulaikomi, kas gali atitolinti SOC ir erodinti naudotojų pasitikėjimą.
Ar gaujų detekcija vis dar veiksminga, kai užpuolikai naudoja AI generuotus gaujų laiškų?
Senasis gramatikos ir raidžių atpažinimo būdas jau nebeveiksmingas, tačiau elgsenos pagrindu ir ryšių žemėlapių detekcija vis dar gali būti efektyvi, kadangi ji nepriklauso nuo teksto kokybės.
Ar vidutinėms įmonėms reikia įsigyti specializuotus AI detekcijos agentus?
Jeigu jau naudojate Microsoft 365 ar Google Workspace, galite pirmiausia įjungti jų natyvą saugumo funkciją ir nustatyti DMARC, kad būtų įgalinta. Jei turite didelę BEC riziką arba esate priverstas laikytis saugumo reikalavimų, tuomet galite įvertinti specializuotus ICES sprendimus.
Kiek laiko trunka įdiegti tokias sistemas?
API lygio schemos techninis prisijungimas gali trukti nuo kelių minučių iki kelių dienų, tačiau visiškai įdiegti rekomenduojama 90 dienų laikotarpyje, tris etapais: 30 dienų paralelinis bandymas, 30 dienų pilnas diegimas ir 30 dienų visiškai įdiegtas darbas.
