DI prieš phishingą: kai laiškai nebeturi gramatikos klaidų
·
DI prieš phishingą skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?
AWS rašo apie DI sugeneruotą phishingą. Seniau dar galėjai juoktis iš keistos gramatikos ir neaiškių sakinių. Dabar laiškai mandagūs, tikslūs, su kontekstu ir dažnai parašyti geriau nei dalis tikrų vidinių laiškų. Va čia ir prasideda smagumas. Tik nelabai smagus.
Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?
KAS NUTIKO
AWS pavyzdyje Amazon Bedrock naudojamas analizuoti el. laiškus ir aptikti požymius, kurių seni filtrai gali nematyti: personalizaciją, toną, kontekstą, užmaskuotą spaudimą veikti greitai.
Įmonėse vis dar dažnai girdžiu: „mūsų žmonės atpažins“. Atpažins ką? Laišką be klaidų, su tikru kliento vardu, tikra situacija ir prašymu, kuris atrodo kaip normalus darbo dienos chaosas?
KODĖL TAI SVARBU
DI prieš phishingą svarbus todėl, kad puolėjai jau naudoja tuos pačius įrankius, kuriuos naudoja verslas. Jei gynyba lieka 2018 metų lygio, puolimas tampa greitesnis.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.
KĄ TAI REIŠKIA VERSLUI
Verslui reikia derinti mokymus, techninius filtrus ir aiškias procedūras. Vien darbuotojo budrumo neužteks, ypač kai atakos tampa personalizuotos.
- atnaujinti phishing mokymus pagal DI sugeneruotus pavyzdžius
- turėti antrą patvirtinimą mokėjimams ir jautriems veiksmams
- naudoti analizę, kuri vertina kontekstą, ne tik raktinius žodžius
- pranešimus apie įtartinus laiškus padaryti labai paprastus
Vienas pratimas: paimkite tris realius vidinius laiškus ir sukurkite saugumo mokymą, kuriame darbuotojai turi atskirti tikrą prašymą nuo labai panašaus phishing scenarijaus.
KUR PASISLĖPUSI RIZIKA
Rizika – kaltinti žmogų po klaidos. Jei procesas leidžia vienu laišku pakeisti sąskaitą ar išsiųsti duomenis, problema yra ne tik žmogus.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Peržiūrėkite, kokiems veiksmams jūsų įmonėje užtenka vieno el. laiško. Ten reikia papildomo patvirtinimo.
Šaltinis: Amazon Web Services.
DUK
Kas yra DI sugeneruotas phishingas?
Tai apgaulingi laiškai ar žinutės, sukurti naudojant generatyvinį DI.
Kodėl jis pavojingesnis?
Nes gali būti taisyklingas, personalizuotas ir pritaikytas konkrečiam žmogui.
Ką daryti įmonei?
Derinti techninius filtrus, mokymus ir aiškias patvirtinimo procedūras.
Jei norite DI naudoti ne dėl mados, pradėkite nuo vieno proceso. Paimkite užduotį, kuri kartojasi kas savaitę, susirašykite žingsnius ir tik tada junkite įrankį. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.
