AI aģenta praktiska rokasgrāmata phishing e-pastu noteikšanai: 2026. gada uzņēmumu izvēles un izvietošanas pilna analīze
No SPF/DKIM/DMARC līdz lielu modeļu semantiskajai analīzei – dziļi sadalīts, kā AI vadīta anti‑phishing dzinēja tehnoloģija tiek īstenota reālās draudu vidēs
Daniel Nikulshyn
Editor
Draudu ainava
Kādēļ zvejniecības e-pastu detekcija joprojām ir 2026. gada galvenais uzbrukuma vektors
Tomēr, lai arī e-pasta drošības nozare ir attīstījusies vairāk nekā 20 gadus, zvejniecības e-pastu (phishing) joprojām ir galvenais ieejas punkts, caur kuru uzņēmumi cieta no datu noplūdes. Saskaņā ar Verizon daudzu gadu izdotajiem „Datu noplūdes izmeklējuma ziņojumiem” (DBIR), sociālās inženierijas un akreditācijas izlaupīšana ir ilgu laiku saglabājusies augstā līmenī datu noplūdes gadījumos, bet elektrisko ziņu e-pasts ir visbiežāk izmantotais šo uzbrukumu veids. Vikipēdijas definīcija par zvejniecības e-pastu norāda, ka tās kodols ir uzbrucēja maskēšanās par uzticamu entītiju, kā arī mēģinājums panākt, lai upuris atdotu akreditāciju, veicu pārskaitījumu vai instalētu kaitīgu programmatūru. Kopš 2022. gada, ģeneratīvās AI plaša pieejamība nozīmīgi samazinājusi zvejniecības e-pasta saturam izveidošanas izmaksas. Iepriekšējie pašiem noteiktie noteikumi par to, kā atpazīt zvejniecības e-pastu, balstoties uz ortogrāfiskajām kļūdām un sliktu gramatiku, zūd. - lielais valodas models var ģenerēt pilnīgi perfektu gramatisku un uzņēmuma kultūras noskaņojumu, kā arī pielāgot saturu sasaistībā ar mērķa publiskajām sociālajām profilēm, tā saucamās „šķēršļu zvejniecības” (spear phishing) un „uzņēmumu e-pasta kompromisa” (BEC, Business Email Compromise) gadījumos. BEC ir īpaši svarīgi. FBI interneta noziedzības sūdzību centrs (IC3) daudzos gados savos gadagrāmatās ir iekļāvis BEC kā vienu no lielākajām finanšu zaudējumu cilēm, šo uzbrukumu veidu bieži vien nelīdzinot nevienu kaitīgu saiti vai pielikumu, tikai sociālās inženierijas manipulācijā, kas liedz finanšu personālam pārskaitījumus, padarot tradicionālās metodes, kas balstās uz signaturem un melnajām sarakstiem, pilnīgi neefektīvām. Tieši šāda „bez papildu slādņa” uzbrukumu pieaugums ir vadījis AI valodas modeļu attīstību, kuri balstās uz valodas modeļa izpratni, priekšplāna virsma. Šie aģenti vairs ne tikai skatās uz saitēm un pielikumiem, bet analīze arī nolūka, attieksmēm un valodas modeļiem, kas veido šīs rokasgrāmatas tehnisko kodolu.
- Phishing - Wikipedia — Vikipēdijas definīcija par zvejniecības e-pastu, tipiem un vēsturi
- FBI IC3 gada ziņojums — FBI interneta noziedzības sūdzību centra publicētās BEC zaudējumu statistikas
Tehnoloģiskā bāze
Autentificēšanas protokols ir pamats, bet tālu no galamērķa
Jebkura nopietna phisinga detekcijas shēma balstās uz trim galvenajiem e-pasta autentificēšanas protokoliem: SPF, DKIM un DMARC. SPF (Sūtītāja politkas struktūra) ar DNS ierakstu deklarē, kuri serveri ir tiesīgi pārstāvēt konkrēto domēnu; DKIM (DomainKeys Identified Mail) izmanto šifrētu parakstu, lai verificētu, ka e-pasts pārsūtīšanas laikā nav mainīts; DMARC (Domain-based Message Authentication, Reporting and Conformance) norāda uz protokola neizpildes gadījumā un sniedz kopsavilkuma ziņojumu. Vikipēdijas DMARC ieraksts skaidro, ka tā galvenais ieguldījums ir 'atbilstība' (alignment) — tiešām SPf/DKIM verificēšanas domēns un lietotāji redzamais no sūtītāja domēns ir vienādīgi, tādējādi novēršot domēna izvilināšanu. Google un Yahoo 2024. gadā sāka prasīt DMARC lietošanu lielos daudzumos no sūtītājiem, šo rīcību ievērojami samazinot tiesīssaprātīgo domēnu izvilināšanu. Tomēr šie protokoli var atrisināt tikai 'kas ir tiesīgi izmantot šo domēnu' jautājumu. Tie ir nevarējuši noskrējiens pret divām augstas riska uzbrukumiem: kad uzbrucēji reģistrē līdzīgu domēnu ar mērķa līdzīgu nosaukumu, un kad uzbrucēji ieņem legālu partnera e-pasta adresi un sāk uzbrukumu, kad visa autentificēšana ir izdevusies. Šeit iesaistās AI aģenti. Tie izmanto autentificēšanas rezultātus kā vienu no daudziem faktoriem un nevis kā vienīgo nosacījumu, un pieliek sūtītāja uzvedības analīzi, semantisko mērķa analīzi un sakaru shēmu, lai klātu autentificēšanas protokola aizsegumu. Šo sadalījumu izpratne ir pamats, kuram vērtējot jebkuru piegādātāju, var izvēlties no 'mūsu atbalstīt DMARC' tipa runājuma.
- DMARC - Wikipedia — DMARC protokola darbības princips, atbilstības mehānisms un stratēģiju veidi
- DKIM - Wikipedia — DKIM šifrētā paraksta verificēšanas tehnikas detalizēti
Dzinēja iekšējā daļa
AI aģentu tehnisko pilnvaru analīze
Mūsdienu AI phishingu aģenti parasti sastāv no četrām slāņu tehnikas. Pirmā slānis ir tradicionālā deterministiska detekcija: URL reputācijas datubāze, piemērotāju smilšu kaste, piemērotāju hash salīdzinājums — šī daļa ir nostiprinājusies, galvenokārt aizsargājot no zināmām draudēm. Otrā slānis ir statistika un mašīnzemapātnes izstrāde, izgūstot simtiem signālu, piemēram, sūtēja domēna reģistrācijas ilgums, pirmā komunikācijas signāls, atbilžu adrese atšķiras no sūtēja adrese, slēptie Unicode līdzīgie simboli utt. Trešā slānis ir šo gadu svarīgākā paātrinājuma: dabiskās valodas apstrāde un liela valodas modeļa vadītās semantisko mērķu analīzes. Dzinējs vairs ne vienīgi jautā 'vai šī saite ir droša', bet 'ko šī epistule mēģina man darīt'. Tas var noteikt spiedienu (piemēram, 'lūdzu, pabeidziet pārskaitījumu 30 minūšu laikā'), varoņa maskēšanu (uzturējoties par CEO), kā arī runas struktūras izmaiņas. OpenAI, Anthropic utt. ražotāju lielo modeļu API ir daudz labāk precīza šāda semantiskā analīze, bet arī nesa lēmumus par izdevumu, aizkavējumu un konfidencialitāti. Ceturtā slānis ir attiecību shēma un uzvedības pamatvirsa. Aģents, izanalizējot organizācijas iekšējās un ārējās komunikācijas, izveido katras nosūtītāja 'parastās uzvedības portretu': parasti nosūta ziņojumus kurā laikā, izmanto kādus ierīces, ar ko komunicē, kādu valodu izmanto. Kad epistule atšķiras no pamatvirss (piemēram, CFO nezināmā no IP pieprasa steidzamu pārskaitījumu), sistēma dod augstu riska novērtējumu. Šāda metode, balstīta uz izņēmumu detekciju, ir īpaši efektīva pret BEC uzbrukumiem, jo tā nebalstās uz zināmām parakstiem. Praktiķi vērtējot, ir jāuzdod piegādātājiem: vai semantiskā analīze ir noteikti noteikumi vai īsti modelēšana? Cik ilgi ir vajadzīgs mācīšanās periods uzvedības pamatviršai? Kā kļūdas atgriezeniski ietekmē modeļa uzlabošanu? Šo jautājumu atbildes sniedz daudz vairāk par produktu reālo līmeni nekā vienkārši teikts 'mēs izmantojām AI'.
- OpenAI platformas dokumentācija — Lielo modeļu API oficiālā dokumentācija semantiskai mērķu analīzei
- Anti-phishing software - Wikipedia — Pretrunājošās programmatūras tehnisko klasifikāciju un detekcijas metožu kopsavilkums
Arhitektūras lēmumi
Vārtu līmeņa vs. API līmeņa: divu izvietošanas arhitektūru izvēle
Izvēles laikā visgalvenākā arhitektūras atšķirība ir detektēšanas punkts. Tradicionālā drošības e-pasta vārti (SEG, Secure Email Gateway) ir izvietoti e-pasta plūsmas ieejā, mainot MX ierakstus, lai visi ienākošie e-pasti tiešām tikušu novirzīti uz detekcijas servisam, pirms tie tiek nosūtīti uz pastkasti. Šī metode ir pilnīga, neatskaitot no e-pasta platformas API, bet trūkums ir tas, ka nevar redzēt jau nosūtīto e-pasto turpmākās izmaiņas (piemēram, savācēju saites, kas aktivizējas ar pazeminātu aktivizāciju), un grūti analizēt iekšējo horizontālo zvejošanu. Nesen ir pieaugusi interese par API līmeņa integrāciju (bieži sauktu par ICES, Integrated Cloud Email Security). Tā lasa e-pastu tiešām no e-pasta platformas, izmantojot Microsoft Graph vai Google Workspace API, un veic iekšējo vai pēc tam skenēšanu. Šīs metodes priekšrocības ir tādas, ka izvietošana ilgst dažas minūtes, nav nepieciešams mainīt MX ierakstus, un var redzēt iekšējo e-pasta plūsmu un atbalsta e-pasta atsaukšanu pēc nosūtīšanas (claw-back). Microsoft Defender for Office 365 un Google Workspace iebūvētā drošība ir šīs metodes pārstāvji. Abas arhitektūras nav savādākas. Daži attīstīti uzņēmumi izmanto 'vārtu Metode, lai veidotu smagos filtrus + API slānis, lai veidotu precīzāku pārbaudi'. Praktiķi ir jāsver: vārtu shēma ir kontrolierama situācijās, kurā ir jābūt atbilīgai, bet tās izmantošana prasa lielāku darba daudzumu; API shēma ir vieglāka izvietot, tai ir labāka redzamība, bet tā ir atkarīga no platformas API ātruma un atļaujām un arī no tā, ka tuvumā nozvejojošie e-pasti īslaicīgi var būt glabāti lietotāja saņemšanas kārtā. Bieži vien nozīmīgi novērtējumi ir datu atrašanās vieta un konfidencialitāte. API līmeņa shēmai ir jāautorizē trešās puses, lai tā varētu izlasīt visu e-pasta saturu, un šo izvēli ietekmē GDPR vai nozarei noteiktie noteikumi. Jebkurš piegādātājs ir jāapstiprina datu apstrādes vietā, saglabāšanas periodā un vai e-pasta saturu izmanto, lai veidotu vispārēju modeļu apmācību.
- Microsoft Defender for Office 365 — Oficiālā mikrosofta dokumentācija par e-pasta draudu aizsardzību
- Email filtering - Wikipedia — E-pasta filtrēšanas un drošības vārtu tehniskais fons
Izvēles metodoloģija
Novērtējuma pamatne: ko un kā novērtēt
Gandrīz katrs piegādātājs apgalvo '99% vai augstāku atklājamo dekodēšanu', bet šis cipars bez testa datiem ir bez nozīmes. Es ieteiku drošības komandām izveidot novērtējuma pamatni, kas sastāv no četriem daļējiem kvadrātiem: atklājēja efektivitāte, nepareizo atlūgumu noslogojums, tehnisko resursu lietojuma pieredze un kopējās izmaksas. Atklājēja efektivitātes dimensijā galvenais nav kopējais precizitātes līmenis, bet atsevišķu veidu rādītāji: par ļaunīgiem saitēm, par pielikumiem ar ļaunīgu programmatūru, par tīrā teksta BEC un par iekšējo horizontālo phishingu atsevišķi mērījot atsauksmes koeficientu. Visvērtīgākā prakse ir izmantot savas vēsturiskās neatklājēja paraugus (anonimizēti) regresijas testam, nevis atkarīties no piegādātāja sniegto paraugu demonstrācijām. Turklāt, ir jāprasa vismaz 30 diennakšu paralēlās pieredzes mode (shadow mode), lai jaunais dzinējs varētu novērtēt, neietekmējot ražošanu, un pēc tam salīdzināt ar faktiskajiem rezultātiem. Nepareizi atzīšana ir visvieglāk lejupējot akceptējamākā izmaksu. Dekodēšanas shēma, kas izskatās kā 0,1% nepareizo atzīšanu, lietojumā, kas apstrādā miljoniem e-pastu dienā, nozīmē dienā simts normālu e-pastu kļūdaini izolēšanu, kas var tieši salūzt SOC un ietekmēt lietotāju uzticību sistēmai. Novērtējuma laikā ir jāreģistrē katras nepareizas atzīšanas izskatīšanās laiks un jātestē piegādātāja atgriezeniskās mācīšanās cikla darbības ātrums. Tehnisko resursu un izmaksu dimensijā ietilpst: politikas konfigurācijas granulācija un lasāmība, integrācija ar SIEM/SOAR, notikumu izmeklēšanas saskarņu lietojamība un cenu modeļi (piemēram, e-pasta adrese, e-pasta daudzums vai licence). Slēptās izmaksas bieži vien rodas specifisko pakalpojumu, regulēšanas cikla un papildu pirkuma draudu izpētes abonēšanā. Visus šos faktorus iekļaujot lēmuma tabulā, var izvērsties izvēloties patieso TCO, kas var būt daudz augstāka par budžetu.
- Precision and recall - Wikipedia — _atklājēja sistēmas precizitātes un atsauksmes koeficienta līdzsvarots
Aizsardzības spēles
Pretrunīgā reālā situācija: kad uzbrucēji izmanto AI
E-pasta phishingu atklājējs ir ilggadēja spēle starp aizsardzību un uzbrukumu. Uzbrucēji jau sākuši izstrādāt metodes, kā apiet AI atklājējus: iebūvējot slēptus 'norādījumu ievadīšanu' (prompt injection) tekstus e-pastā, mēģinot manipulēt LLM analīzes dzinējus; izmantojot attēlus, lai pārvadātu tekstu, un tādējādi izvērtušos no teksta skenēšanas; vai arī izmantojot likumīgas mākoņu dokumentu koplietošanas saites (Google Docs, SharePoint), lai ļaunprātīga satura tikai daudzkārtēju pāreju laikā izpaudās. Vikipēdijas ieraksts par pretrunīgo mašīnmācīšanos (adversarial machine learning) norāda, ka jebkura modelī balstīta atklājēja sistēma ir pakļauta riskam tikt apkrāptai ar rūpīgi konstruētiem paraugiem. Tas nozīmē, ka piegādātājiem, kas atbalstās tikai uz vienu lielu modeli, var būt vērā ņemams riska līmenis. Stabilākai shēmai vajadzētu būt daudzdzinēju integrācijai, kur nebūt neviens signāls varētu izdarīt finālu lēmumu. Cita reālā situācija ir 'atklājēja nogurums'. Ja sistēma bieži rāda riska karogus, lietotāji var sākt to pazīt un ignorēt. Tādēļ labākās produkta shēmas darbojas riska līmeņu iedalījumā — tikai augstas riska e-pastiem tiek piemērotas stingrākas kontrolējošās darbības, vidējiem un zemu riska e-pastiem tiek sniegts vieglāks paziņojums, lai piesaistītu lietotāja uzmanību svarīgākajām lietām. Tas ir produkta dizaina jautājums, nevis vienkārši tehniskais, bet tieši ietekmē aizsardzības efektu. Beidzot, tehnoloģija nevar aizstāt cilvēka apmācību. Jauktais AI aizsardzības līdzeklis ir jālieto kopā ar regulāriem phishinga imitācijas treniņiem un darbinieku drošības apziņas izglītību. AI aizsardzības līdzekļa pielietojums ir 'samazināt ļaunprātīgo e-pastu skaitu, kas nonāk cilvēka acīs, un sniegt konteksta palīdzību', nevis 'iznīcināt visu phishingu', šādi ir reālistiska cerību pārvaldība.
- Adversarial machine learning - Wikipedia — Pretrunīgā mašīnmācīšanās apdraud atklājēja sistēmu
- Anthropic drošības pētījumi — Pētījumi par norādījumu ievadīšanu un modeļu drošību
Praktiskā rokasgrāmata
Implementācijas ceļvedis: 90 diennakts izvietošanas plāns
Balstoties uz vairākkārtējām izvietošanas pieredzē, es ieteiktu AI phishing e-pastu aizsardzības aģentu implementāciju sadalīt trīs 30 diennakšu posmos. Pirmajā 30 diennakšu posmā ir paredzēts veikt bāzes līnijas un paralēlās testa darbības: neemainot esošo e-pastu plūsmu, jaunu dzinēju iespējams pieslēgt shadow mode, savācot tā novērtējumu par reālajiem e-pastiem, salīdzinot to ar esošo stāvokli, kvantificējot jaunatklājumus un kļūdainos trāpījumus. Turklāt jāpabeidz SPF/DKIM/DMARC veselības pārbaude, nodrošinot, ka autentifikācijas pamati ir stabili — daudzas organizācijas šajā solī atklāj, ka viņu DMARC vēl joprojām ir p=none. Otrajā 30 diennakšu posmā notiek grižu pārslēgšana un stratēģijas optimizācija. Ir jāizvēlas riska kontrolējama nodaļa (parasti finanšu vai augstākās vadības asistenta komanda ir BEC augsta riska grupa) un sākt lietot stingro aizkavēkļu funkciju, cieši uzraudzot kļūdainos trāpījumus un izveidojot ātru atbrīvošanas kanālu. Šī posma galvenais rezultāts ir stratēģijas bāzes līnija un uzlabota lokācijas procedūra (playbook), nosakot, kāda līmeņa brīdinājumus sistēma var automatizēti izskatīt un kas prasa SOC vadības lēmumu. Trešajā 30 diennakšu posmā notiek pilnīga izvietošana un darbības nostiprināšana. Jāsavieno aizsardzības aģents ar SIEM/SOAR, ļaujot automatizēti atsaukt, izolēt un izveidot notikuma žurnālu; jāizveido kļūdaino trāpījumu atgriezeniskās saites procesa regulārs process, nodrošinot, ka katrs kļūdaini aizkavētais e-pasts var tūlīt atkal tikt ievadīts modelī; turklāt jāsāk pirmā kārtas phishing simulačiju, pārbaudot cilvēka un mašīnas sadarbības efektīvu aizsardzības efekti. Atcerieties, ka ir jāsaglabā atgriezeniskais plāns. Jebkura sistēma, kas atkarīga no trešo pušu API un modeļiem, var īsi pazust darbībā saistībā ar piegādātāja kļūdu, modeļu atjaunināšanu vai ierobežojumu, tādēļ ir svarīgi iepriekš nosprēst pazeminošās stratēģijas (piemēram, automatizēti atgriezties pie konservatīvām noteiktām noteikumiem) un šo nosacījumu ietvert līgumā, kas ir aizsargājošā nozares darbinieku aizsardzības pēdējā līnija.
- Security information and event management - Wikipedia — SIEM/SOAR un e-pastu detekcijas sistēmas savienošanas fona informācija
Resursi
- Phishing - Wikipedia
Phishing uzbrukumu definīcijas, veidi un vēsturiskā attīstība
- DMARC - Wikipedia
E-pasta autentifikācijas un pretviltošanas protokola darbības princips
- Microsoft Defender for Office 365 dokumentācija
Microsoft oficiālā e-pasta draudu aizsardzības produkta dokumentācija
- OpenAI platformas dokumentācija
Lielo modeļu API semantiskās nodoma analīzes oficiālie materiāli
- Anthropic pētījumu mājas lapa
Piedāvājumu injekcijas un modeļa drošības pētījumi frontā
Biežāk uzdotie jautājumi
AI phishing detektēšanas aģents var pilnībā aizstāt tradicionālo drošo e-pastu vārteju?
Parasti tas nevar pilnībā aizstāt, bet darbojas kā papildinājums. API līmeņa AI detektēšana BEC un iekšējā horizontālajā phishingā strādā labāk, bet vārteja joprojām ir vērtīga iekļautai iekšu filtrēšanai un aizkaves kontrolei. Lielākā daļa nopietnu organizāciju izmanto dziļu aizsardzību, abi slāņi pastāv.
Izvietojot API līmeņa risinājumu, kas nepieciešams pilnīgs piekļuves atļaujas lasīt visus e-pastus – kādas ir atbilstības riski?
Galvenais ir dati, to glabāšana, uzglabāšanas periods un vai tie tiek izmantoti modeļa apmācībai. Uzņēmumiem, kas pakļauti GDPR vai nozares regulām, jāapstiprina piegādātāja datu apstrādes vieta, jāparaksta DPA vienošanās un jānodrošina, ka e-pasta saturs netiks izmantots vispārējo modeļu apmācībai.
Kāpēc, ja ir DMARC, joprojām var tikt pakļauts phishing?
DMARC spēj novērst domēna viltošanu, bet tas nespēj aizsargāt pret līdzīgiem domēniem (uzbrucējs izmanto savu likumīgo domēnu) vai pret reāli kompromitētiem partneru e-pastiem. Šāda veida uzbrukumi pāriet caur autentifikāciju. Tieši tāpēc ir nepieciešama AI semantiskā un uzvedības analīze.
Vai var ticēt piegādātāja solītajam 99 % detektēšanas rādītājam?
Detektēšanas rādītāji, kas nav saistīti ar reālu testu kopu, ir maznozīmīgi. Jāpieprasa atsevišķas klases atgūšanas rādītāji, jāveic regresijas pārbaude, izmantojot pašu organizācijas vēsturiskos nepietiekami atklātos gadījumus, un jāveic vismaz 30 dienu paralēls mēģinājuma darbs, lai pārbaudītu rezultātus.
Kādu operatīvo slogu rada nepatiesi pozitīvi rezultāti?
Tie tiek bieži novērtēti pārāk maz. Pat 0,1 % nepatiesi pozitīvu rādītājs pie miljoniem e-pastiem nozīmē tūkstošus normālu e-pastu dienā, kas var pārslogot SOC un erodēt lietotāju uzticību. Novērtējot jāizmēra nepatiesi pozitīvu apstrādes laiks un atgriezeniskās saites mācīšanās ātrums.
Vai joprojām darbojas detektēšana, ja uzbrucēji izmanto AI, lai ģenerētu phishing e-pastus?
Tradicionālās gramatikas/pareizrakstības metodes jau ir neefektīvas, bet uzvedības bāzes un attiecību grafu anomāliju detektēšana joprojām darbojas, jo tā nav atkarīga no teksta kvalitātes. Stabilam risinājumam jābūt daudzām integrētām dzinējām, lai izvairītos no mērķtiecīgiem pretinieka paraugiem.
Vai mazajiem un vidējiem uzņēmumiem ir vajadzīgs iegādāties īpašu AI detektēšanas aģentu?
Ja jau izmanto Microsoft 365 vai Google Workspace, var vispirms pilnībā aktivizēt to iebūvēto drošības funkcionalitāti un iestatīt DMARC uz „enforce”. Kad rodas augsts BEC risks vai atbilstības prasības, tad jāapsver īpašs ICES risinājums – vieglāks produkts ar maksu par katru pastkasti ir kļuvis daudz pieejamāks.
Cik ilgi parasti jāņem laiks, lai izvietotu šādu sistēmu?
API līmeņa tehniskā integrācija var ilgt no dažām minūtēm līdz dažām dienām, bet pilnīgai ieviešanai ieteicams 90 dienu trīs posmu plāns: 30 dienas paralēls mēģinājuma darbs, 30 dienas pelēkās zonas regulēšana, 30 dienas pilna izvietošana un operāciju nostiprināšana, lai kontrolētu nepatiesi pozitīvus gadījumus un pārejas riskus.
