Klientų aptarnavimo komandos susiduria su unikaliu saugumo iššūkiu: jų darbas reikalauja atidaryti el. laiškus iš nežinomų siuntėjų, apdoroti priedus ir spustelėti nuorodas, kurias siunčia nepažįstami žmonės. Dėl to klientų aptarnavimo gautieji tampa pagrindiniu sukčiavimo atakų taikiniu. Vienas sėkmingas sukčiavimo el. laiškas, pasiekęs klientų aptarnavimo agentą, gali sukelti pavogtus prisijungimus, duomenų saugumo pažeidimus ar šoninį judėjimą į vidines sistemas.
Gera žinia ta, kad daugiasluoksnė gynybos strategija, derinanti el. pašto autentifikavimą, DI pagrįstą filtravimą ir agentų mokymą, gali sustabdyti didžiąją dalį sukčiavimo bandymų dar prieš jiems pasiekiant žmogų. Šis vadovas padės jums per kiekvieną sluoksnį – nuo pagrindinių protokolų, kuriuos turėtų turėti kiekvienas domenas, iki pažangaus DI pagrįsto bilietų patvirtinimo, pagaunančio grėsmes, kurių tradiciniai filtrai nepastebi.
Sudėtingumas: Vidutinis Įgyvendinimo laikas: nuo 1 iki 3 dienų pilnai konfigūracijai Būtinos sąlygos: Administratoriaus prieiga prie jūsų el. pašto serverio ar pagalbos skyriaus platformos, prieiga prie jūsų domeno DNS įrašų
Ko jums prireiks
| Įrankis ar prieiga | Tikslas |
|---|---|
| DNS valdymo konsolė | SPF, DKIM ir DMARC įrašų konfigūravimas |
| El. pašto serverio administratoriaus prieiga | Serverio šiukšlių filtravimo nustatymas |
| Pagalbos skyriaus platformos administratorius | Automatizavimo taisyklių ir DI filtro nustatymų konfigūravimas |
| Saugumo sąmoningumo mokymo medžiaga | Agentų mokymas atpažinti sukčiavimą |
| DI šiukšlių filtras (toks kaip LiveAgent DI šiukšlių ir nereikšmingų laiškų filtras ) | Pažangių grėsmių, apeinančių tradicines taisykles, sulaikymas |
1 žingsnis: Įdiegkite el. pašto autentifikavimo protokolus (SPF, DKIM, DMARC)
El. pašto autentifikavimas yra jūsų pirmoji gynybos linija. Šie trys protokolai veikia kartu, kad užkirstų kelią užpuolikams apsimesti jūsų domenu ir padeda gavėjų serveriams atpažinti suklastotus el. laiškus.
SPF (Sender Policy Framework) nurodo visam pasauliui, kurie pašto serveriai turi teisę siųsti el. laiškus jūsų domeno vardu. Be SPF, užpuolikas gali suklastoti „siuntėjo" adresą, kad apsimestų jūsų įmone.
- Prisijunkite prie DNS valdymo konsolės
- Pridėkite TXT įrašą savo domenui, nurodantį, kurie IP adresai ar pagalbininkų vardai gali siųsti paštą
- Pavyzdys:
v=spf1 include:_spf.google.com ~all
DKIM (DomainKeys Identified Mail) prideda kriptografinį parašą prie kiekvieno siunčiamo el. laiško. Gavėjų serveriai patvirtina šį parašą pagal viešąjį raktą, paskelbtą jūsų DNS, kad įsitikintų, jog el. laiškas nebuvo pakeistas perdavimo metu.
- Sugeneruokite DKIM raktų porą per savo el. pašto tiekėją ar pašto serverį
- Paskelbkite viešąjį raktą kaip TXT įrašą savo DNS
- Konfigūruokite savo pašto serverį, kad jis pasirašytų siunčiamus pranešimus privačiu raktu
DMARC (Domain-based Message Authentication, Reporting, and Conformance) sujungia SPF ir DKIM su politika. Jis nurodo gavėjų serveriams, ką daryti, kai el. laiško autentifikavimas nepavyksta: nieko nedaryti (p=none), įdėti į karantiną (p=quarantine) arba visiškai atmesti (p=reject).
- Pradėkite nuo
p=noneir stebėkite DMARC ataskaitas, kad nustatytumėte teisėtus siuntimo šaltinius, kuriuos galėjote praleisti - Kai įsitikinsite, kad visas teisėtas paštas sėkmingai autentifikuojamas, pereikite prie
p=quarantine - Maksimaliai apsaugai nustatykite
p=reject, kad sukčiavimo el. laiškai niekada nepasiektų jokių gautųjų
Įspėjimas: Perėjus tiesiai prie
p=rejectbe stebėjimo, teisėti el. laiškai iš trečiųjų šalių paslaugų gali būti tyliai atmesti. Visada pradėkite nuop=noneir pirmiausia peržiūrėkite ataskaitas.

2 žingsnis: Įdiekite saugų el. pašto šliuzą ar debesies el. pašto filtrą
Net ir įdiegus autentifikavimą, užpuolikai gali siųsti sukčiavimo el. laiškus iš domenų, kuriuos jie kontroliuoja. Saugus el. pašto šliuzas (SEG) tikrina kiekvieną gaunamą pranešimą ir blokuoja arba įdeda į karantiną tuos, kurie atitinka grėsmių modelius.
Dauguma šiuolaikinių el. pašto platformų turi įmontuotą apsaugą:
- Google Workspace naudotojai turėtų įjungti pažangią sukčiavimo ir kenkėjiškų programų apsaugą administratoriaus konsolėje, kuri nuskaito pranešimus ieškodama kenkėjiškų nuorodų, neįprastų priedų tipų ir apsimetimo bandymų
- Microsoft 365 naudotojai turėtų konfigūruoti kovos su sukčiavimu politikas Microsoft Defender for Office 365, įskaitant apsaugą nuo apsimetimo pagrindiniais kontaktais ir domenais
- Atskiri pašto serveriai turėtų integruoti šiukšlių aptikimo variklį, pvz., SpamAssassin , kuris naudoja Bayesinį filtravimą, blokavimo sąrašus ir euristines taisykles kiekvienam pranešimui įvertinti
Renkantis el. pašto saugumo sprendimą, ieškokite šių galimybių:
- URL perrašymas ir apsauga spustelėjimo momentu: Perrašo nuorodas gaunamuose el. laiškuose ir realiu laiku patikrina jas spustelėjus, pagaunant grėsmes, kurios suaktyvėja po pristatymo
- Priedų smėlio dėžė: Atidaro įtartinus priedus (Office dokumentus, PDF, archyvus) izoliuotoje virtualioje aplinkoje prieš pristatymą
- Apsimetimo aptikimas: Nustato rodomo vardo klastojimą ir panašius domenus, kurie imituoja vadovus ar patikimus partnerius
- Rizikingų failų tipų blokavimas: Karantinuoja arba atmeta
.exe,.vbs,.js, makrokomandas turinčius Office dokumentus ir slaptažodžiu apsaugotus archyvus
3 žingsnis: Konfigūruokite savo pagalbos skyriaus platformos įmontuotą apsaugą nuo šiukšlių
Kai el. pašto lygmens filtravimas jau veikia, kitas sluoksnis yra jūsų pagalbos skyriaus ar bilietų sistemos viduje. Dauguma platformų turi vietinį šiukšlių aptikimą, kuris pagauna tai, ką praleido el. pašto šliuzas.
Zendesk naudotojams: Šiukšlių filtras yra įjungtas pagal nutylėjimą pagalbos centro turiniui. Bilietams, gaunamiems el. paštu, konfigūruokite trigerius, kurie aptinka šiukšlių modelius ir nukreipia juos į sustabdytų ar šiukšlių rodinį. Zendesk skaito X-Spam-Status antraštę, kad nustatytų pažymėtus pranešimus.
Freshdesk naudotojams: Nueikite į Administratorius > Kanalai > Portalai ir įjunkite CAPTCHA viešai matomose formose, kad blokuotumėte automatizuotus botų siuntimus. Platformos aktyvus šiukšlių filtras priskiria balą kiekvienam gaunamam bilietui, ir galite sukurti automatizavimo taisykles, kurios automatiškai uždaro arba ištrina bilietus, viršijančius slenkstį.
LiveAgent naudotojams: LiveAgent siūlo daugiasluoksnį požiūrį į šiukšlių prevenciją. Platformos DI šiukšlių ir nereikšmingų laiškų filtras apdoroja neapdorotus bilietų duomenis, įskaitant pranešimų antraštes, HTML struktūrą ir turinį, įvertindamas kiekvieną pateikimą pagal jūsų apibrėžtą verslo kontekstą. Jis patikimai atskiria teisėtus klientų užklausimus nuo šiukšlių, nepageidaujamo pardavimo kreipimųsi, sukčiavimo bandymų ir kitų neveiksmingų pranešimų.
Įmontuotoms el. pašto paskyroms LiveAgent automatiškai paleidžia visus gaunamus pranešimus per SpamAssassin savo debesies serveriuose. Pranešimai, pažymėti kaip šiukšlė, importuojami su šiukšlės būsena, laikant juos už aktyvios agentų eilės, tačiau vis tiek leidžiant peržiūrėti, jei pasitaikytų klaidingų teigiamų rezultatų.
Jei prijungiate išorinį pašto serverį per Google, Microsoft ar IMAP/POP3 jungtis, LiveAgent nuskaito X-Spam-Status antraštę, kurią prideda jūsų serveris, ir automatiškai pritaiko atitinkamą bilieto būseną.
4 žingsnis: Pridėkite DI pagrįstą šiukšlių ir nereikšmingų laiškų filtrą
Tradiciniai šiukšlių filtrai remiasi žinomais modeliais: blokuotais IP, įtartinais raktiniais žodžiais ir netinkamai suformuotomis antraštėmis. Sukčiavimo atakos organizatoriai tai žino ir nuolat pritaiko savo metodus, kad apeitų taisyklėmis pagrįstą aptikimą. Čia DI pagrįstas filtravimas suteikia kritiškai svarbų papildomą sluoksnį.
DI šiukšlių filtras peržengia raktinių žodžių atitikimą. Jis analizuoja kiekvieno pranešimo intenciją, kontekstą ir prasmę. Jis gali atpažinti, kad šaltas pardavimo pasiūlymas, automatinis pranešimas apie nepristatymą ar sukčiavimo el. laiškas, užmaskuotas kaip slaptažodžio atkūrimo užklausa, nėra tikras klientų aptarnavimo užklausimas, net jei pranešime nėra akivaizdžių šiukšlių signalų.
LiveAgent DI šiukšlių ir nereikšmingų laiškų filtras daro būtent tai. Tai viena iš kelių DI pagrįstų funkcijų, įmontuotų platformoje, veikianti su FlowHunt. Filtras įvertina kiekvieną bilietą pagal konfigūruojamus kriterijus:
- Turinio ir konteksto analizė: DI perskaito visą pranešimą, ne tik ieško raktinių žodžių, kad suprastų, ar bilietas atspindi tikrą kliento problemą
- Šiukšlių ir nereikšmingumo aptikimas: Nustato įprastus modelius, tokius kaip masiniai pranešimai, šalti pardavimo pasiūlymai, sukčiavimo turinys ar beprasmiai įvedimai
- Lanksti logika: Jūs apibrėžiate, kas laikoma aktualu, o kas neaktualu, atsižvelgiant į jūsų konkretų verslą
- Griežtas TRUE/FALSE rezultatas: Filtras grąžina dvejetainį sprendimą, kurį galima naudoti automatizuotiems veiksmams, pvz., žymėjimui, nukreipimui ar bilietų pašalinimui iš standartinių klientų aptarnavimo eilių

DI šiukšlių ir nereikšmingų laiškų filtras veikia kaip platesnio bilietų patvirtinimo ir automatinio atsakymo darbo eigos dalis. Kai gaunamas naujas bilietas, DI agentas įvertina jo aktualumą ir aiškumą. Pranešimai, kurie praeina patvirtinimą, gali gauti automatinį atsakymą iš žinių bazės. Pranešimai, pažymėti kaip šiukšlė, dublikatai arba per daug neaiškūs, kad būtų galima reaguoti, yra atfiltruojami dar prieš jiems pasiekiant žmogų agentą.
Patarimas: DI filtras yra pagrįstas kreditais per FlowHunt. Kiekviena patvirtinimo operacija sunaudoja nedidelį kreditų kiekį, todėl jis yra prieinamas net ir didelės apimties klientų aptarnavimo komandoms. Mokate tik už tas DI operacijas, kurias naudojate.
5 žingsnis: Nustatykite automatizavimo taisykles šiukšlių bilietų karantinui ir valdymui
Vien filtravimo nepakanka. Jums reikia aiškių automatizavimo taisyklių, kurios nustato, kas atsitinka su bilietais, kai jie klasifikuojami kaip šiukšlė. Tikslas yra išlaikyti jūsų agentų eiles švarias, nepašalinant visam laikui nieko, kas galėtų būti klaidingai teigiamas.
Sukurkite šias automatizavimo taisykles savo pagalbos skyriuje:
1 taisyklė: Automatinis didelio pasitikėjimo šiukšlių karantinas
- Trigeris: Sukurtas naujas bilietas
- Sąlyga: DI filtras grąžina FALSE arba SpamAssassin balas viršija slenkstį
- Veiksmas: Nustatyti būseną į Šiukšlė, pašalinti iš visų agentų rodinių, nesiųsti pranešimo
2 taisyklė: Pažymėti vidutinio pasitikėjimo bilietus peržiūrai
- Trigeris: Sukurtas naujas bilietas
- Sąlyga: DI filtras grąžina TRUE, bet turinyje yra įtartinų modelių (neįprastos nuorodos, nežinomas siuntėjo domenas)
- Veiksmas: Pridėti žymą “peržiūra”, nukreipti į skirtą peržiūros eilę
3 taisyklė: Automatinis patvirtintų šiukšlių uždarymas po peržiūros laikotarpio
- Trigeris: Bilietas šiukšlių eilėje yra 30 dienų
- Veiksmas: Ištrinti visam laikui
Svarbu: Niekada iš karto netrinkite šiukšlių bilietų. Visada pirmiausia įdėkite juos į karantiną. Teisėto kliento el. laiškas, netyčia sugautas, yra daug žalingesnis nei keli šiukšlių bilietai jūsų eilėje.
LiveAgent naudotojams DI šiukšlių ir nereikšmingų laiškų filtras grąžina griežtą TRUE arba FALSE rezultatą, kuris tiesiogiai integruojamas su automatizavimo taisyklėmis. Galite konfigūruoti taisykles, kurios naudoja šį rezultatą, kad tiksliai valdytų, kas atsitinka su kiekvienu bilietu: nukreipti jį agentams, pažymėti peržiūrai arba visiškai atmesti.
6 žingsnis: Užtikrinkite viešų bilietų pateikimo kanalų saugumą
Daugelis sukčiavimo bandymų neateina el. paštu. Jie ateina per internetines formas, pokalbių valdiklius ir pagalbos portalus. Šių kanalų apsauga yra būtina.
Įjunkite CAPTCHA visose viešose formose. Šis vienas žingsnis blokuoja automatizuotus botus, kurie per kontaktines formas siunčia tūkstančius šiukšlių ar sukčiavimo pranešimų. Dauguma pagalbos skyriaus platformų turi CAPTCHA kaip įmontuotą parinktį.
Pridėkite “honeypot” laukelius prie individualių formų. “Honeypot” yra paslėptas formos laukelis, kurio tikri naudotojai nemato, bet botai jį užpildo automatiškai. Jei laukelyje yra duomenų, pateikimas tyliai atmetamas.
Ribokite siuntimo dažnį. Apribokite bilietų skaičių, kurį vienas IP adresas gali pateikti per tam tikrą laiko tarpą. Tai apsaugo nuo paslaugų atsisakymo atakų ir skriptais pagrįstų šiukšlių srautų.
Reikalaukite el. pašto patvirtinimo naujiems kontaktams. Išsiųskite patvirtinimo nuorodą prieš leisdami naujam el. pašto adresui kurti bilietus. Tai sukuria papildomą kliūtį užpuolikams, išlikdama valdoma tikriems klientams.
Naudokite DI filtrą visuose kanaluose. DI šiukšlių ir nereikšmingų laiškų filtras apdoroja bilietus iš visų šaltinių, ne tik el. pašto. Nesvarbu, ar pranešimas gaunamas per pokalbį, internetinę formą ar socialinius tinklus, taikoma ta pati patvirtinimo logika.
7 žingsnis: Mokykite klientų aptarnavimo agentus atpažinti sukčiavimą
Jokia techninė kontrolė nėra tobula. Kai kurie sukčiavimo el. laiškai neišvengiamai pasieks jūsų agentus. Kai taip atsitinka, jūsų agentai turi būti paskutinė gynybos linija.
Mokykite agentus atpažinti šiuos įspėjamuosius ženklus:
- Skubos ir autoriteto spaudimas: Pranešimai, reikalaujantys nedelsiant veikti, gresiantys paskyros sustabdymu ar teigiantys, kad jie siunčiami iš aukšto rango vadovo
- Neatitinkantys siuntėjo duomenys: Rodomas vardas sako „IT pagalba", bet tikrasis el. pašto adresas yra iš nesusijusio domeno
- Netikėti priedai ar nuorodos: „Klientas", siunčiantis slaptažodžiu apsaugotą ZIP failą ar nuorodą į nepažįstamą prisijungimo puslapį
- Prašymai pateikti neskelbtiną informaciją: Bet koks el. laiškas, prašantis slaptažodžių, MFA kodų ar vidinės sistemos informacijos
- Neįprastas formatavimas ar kalba: Sukčiavimo šablonuose dažnai būna gramatinių klaidų, nenuoseklaus prekės ženklo naudojimo ar neįprastų formuluočių

Atlikite sukčiavimo simuliacijas, pritaikytas klientų aptarnavimo scenarijams. Standartiniai įmoniniai sukčiavimo testai dažnai yra pernelyg bendriniai. Imituokite realistiškus gaunamus scenarijus, tokius kaip netikri slaptažodžio atkūrimo užklausimai, eskalavimo vadovybės skundai ar tiekėjų programinės įrangos patvirtinimo el. laiškai.
Suteikite mygtuką „Pranešti apie sukčiavimą" vienu spustelėjimu el. pašto programoje ar pagalbos skyriuje. Padarykite pranešimą greitą ir be trinties. Kiekvienas praneštas sukčiavimo el. laiškas laikui bėgant pagerina jūsų automatinius filtrus.
8 žingsnis: Stebėkite, peržiūrėkite ir nuolat tobulinkite
Šiukšlių ir sukčiavimo taktika nuolat keičiasi. Filtras, kuris šiandien veikia puikiai, rytoj gali praleisti ataką. Nuolatinis stebėjimas yra būtinas.
Kartą per savaitę peržiūrėkite šiukšlių eilę. Paskirkite komandos narį bent kartą per savaitę patikrinti šiukšlių ar sustabdytų bilietų aplanką. Atkurkite bet kokius teisėtus bilietus, kurie buvo neteisingai pažymėti, ir pakoreguokite savo taisykles, kad ateityje išvengtumėte panašių klaidingų teigiamų rezultatų.
Sekite pagrindinius rodiklius:
- Per savaitę sugautų šiukšlių bilietų skaičius
- Klaidingų teigiamų rezultatų skaičius (teisėti bilietai, neteisingai pažymėti)
- Sukčiavimo el. laiškų, pasiekusių agentus, skaičius (praleisti)
- Agentų pranešti sukčiavimo bandymai
Reguliariai atnaujinkite savo taisykles. Pridėkite naujų raktinių žodžių, siuntėjų domenų ir modelių, kai juos atrandate. Jei pastebite naują sukčiavimo atakos tipą, sukurkite taisykles, kad jį sugautumėte kitą kartą.
Perauklėkite DI filtrą. Jei jūsų platforma naudoja mašininį mokymąsi, nuosekliai žymėkite neteisingai klasifikuotus bilietus kaip „Šiukšlė" arba „Ne šiukšlė", kad apmokytumėte algoritmą. „LiveAgent" DI bilietų rūšiavimo ir kategorizavimo agentas laikui bėgant mokosi iš jūsų komandos veiksmų, didindamas tikslumą su kiekvienu pataisytu bilietu.
Trikčių šalinimas
| Problema | Galima priežastis | Sprendimas |
|---|---|---|
| Teisėti klientų el. laiškai žymimi kaip šiukšlė | Šiukšlių filtro slenkstis per agresyvus | Sumažinkite šiukšlių balo slenkstį, įtraukite kliento domeną į leidžiamų sąrašą arba peržiūrėkite DI šiukšlių ir nereikšmingų laiškų filtro konfigūraciją |
| Sukčiavimo el. laiškai vis dar pasiekia agentus | Autentifikavimas nesukonfigūruotas, DI filtras neįjungtas arba apėjimo taisyklės per daug leidžiančios | Patikrinkite, ar SPF/DKIM/DMARC yra paskelbti, įjunkite DI filtrą, sugriežtinkite automatizavimo taisykles |
| DMARC ataskaitos rodo, kad teisėtas paštas nepraeina autentifikavimo | Trūksta SPF įrašo trečiosios šalies paslaugai (naujienlaiškis, CRM, sąskaitų išrašymas) | Pridėkite paslaugos siuntimo infrastruktūrą prie savo SPF įrašo arba pasirašykite DKIM per ją |
| Didelis botų siunčiamų šiukšlių kiekis per internetines formas | CAPTCHA išjungta arba neveiksminga | Įjunkite CAPTCHA, pridėkite “honeypot” laukelius, įgyvendinkite siuntimo dažnio ribojimą |
| Agentai nepraneša apie sukčiavimo el. laiškus | Pranešimo procesas per sudėtingas arba agentai bijo kaltės | Pridėkite mygtuką “pranešti” vienu spustelėjimu, sukurkite nekaltinančią pranešimų kultūrą, dalinkitės sukčiavimo statistika su komanda |
| DI filtras naudoja per daug kreditų | Bilietų apimtis didesnė nei tikėtasi arba patvirtinimas vykdomas kiekvienam pranešimui | Koreguokite automatizavimo taisyklę, kad filtras būtų paleidžiamas tik nežinomų siuntėjų pranešimams, arba apdorokite mažo prioriteto kanalus partijomis |
Apibendrinimas
Siekiant neleisti sukčiavimo el. laiškams pasiekti klientų aptarnavimo agentų, reikalingas daugiasluoksnis požiūris. Pradėkite nuo el. pašto autentifikavimo (SPF, DKIM, DMARC), pridėkite saugaus el. pašto šliuzo filtravimą, o tada įtraukite DI pagrįstą aptikimą, kuris pagauna grėsmes, kurių tradicinės taisyklės nepastebi. Konfigūruokite savo pagalbos skyrių automatiškai karantinuoti šiukšles, mokykite savo agentus atpažinti tai, kas praslysta, ir nuolat stebėkite bei tobulinkite savo sistemą.
Stiprių techninių kontrolės priemonių ir DI šiukšlių filtro , kaip LiveAgent, derinys suteikia jūsų klientų aptarnavimo komandai geriausią galimybę sutelkti dėmesį į tikrus klientus, o ne į sukčiavimo grėsmes. Įdiegę šiuos sluoksnius, galite žymiai sumažinti riziką, kad sukčiavimo el. laiškai pasieks jūsų klientų aptarnavimo agentus, tuo pačiu išlaikydami klaidingus teigiamus rezultatus iki minimumo.




