SMS-phishing-teszt alkalmazottak számára: ellenőrzőlista a kezelt

A munkavállalók számára készített SMS-phishing-tesztnek ellenőriznie kell, hogy az emberek felismerik-e, ellenőrizik-e és jelentik-e a gyanús szöveges üzeneteket anélkül, hogy jelszavakat, MFA-kódokat, fizetési adatokat vagy személyes információkat gyűjtenének. A vállalat által kezelt telefonokon a tesztnek ellenőriznie kell az eszköz regisztrációját, a jóváhagyott telefonszám-használatot, a szolgáltatói kézbesítést, a mobil jelentéstételt és az események pontosságát is. A vásárlóknak össze kell hasonlítaniuk ezeket az operatív ellenőrzési mechanizmusokat, mielőtt a sablonkönyvtárakat hasonlítanák össze.

A felügyelt eszközök egyszerűsítik bizonyos kérdéseket, de nem teszik a smishing-szimulációt automatikusan engedélyezetté, magánjellegűvé vagy hasznossá. Egy vállalati telefonszám több rendszerben is tárolható lehet, a mobilbiztonsági eszközök automatikusan ellenőrizhetik a linkeket, és az alkalmazottak továbbra is használhatják az eszközt korlátozott mértékű személyes tevékenységre. Egy biztonságos programhoz dokumentált célra, ellenőrzött címzettforrásra, működő jelentési útvonalra és az összegyűjtött adatokra vonatkozó egyértelmű korlátozásokra van szükség.

Ez az útmutató védelmi célú. Nem tartalmaz megtévesztő SMS-sablonokat, feladó-hamisítási technikákat, a kézbesítés megkerülésére vonatkozó utasításokat, hitelesítő adatok gyűjtésére szolgáló módszereket, illetve útmutatást jogosulatlan teszteléshez.

Határozza meg, mit kell igazolnia az SMS-tesztnek

Kezdje egy olyan viselkedéssel, amelyet a szervezet javítani szeretne. A „mérje meg, ki érint meg” túl homályos, mert egy érintés véletlen lehet, biztonsági szkennertől származhat, vagy független attól, hogy az alkalmazott tudta-e, hogyan kell biztonságosan reagálni.

Hasznos cél lehet annak megállapítása, hogy az alkalmazottak:

szünetet tartanak-e, mielőtt egy váratlan mobilkérésre reagálnának;
ellenőrizik-e a kérést egy jóváhagyott üzleti csatornán keresztül;
jelentik-e a gyanús üzenetet a dokumentált eljárás szerint;
elkerülik-e az érzékeny jóváhagyások SMS-ben történő intézését; vagy
tudják-e, mit kell tenniük, miután gyanús üzenettel léptek kapcsolatba.

Válasszon ki egy fő célt a kísérleti programhoz, és határozza meg, milyen bizonyítékok jelzik a siker elérését. Például a bejelentési magatartáshoz szükség van egy ismert bejelentési címre, visszaigazolásra, a bejelentés osztályozásának rögzítésére, valamint egy eseményre a képzési jelentésben. Ez sokkal értelmesebb elfogadási teszt, mint annak megerősítése, hogy az SMS-szolgáltató visszaadta a kézbesítési állapotot.

Ha a mobil tesztelés egy szélesebb körű program része, használja a phishing-tudatosságot növelő képzés vásárlói útmutatóját a szimulációk, az oktatás, a megerősítés és az irányítás összehangolásához.

Az engedélyezés és a telefonszám tulajdonjogának megerősítése

Az, hogy a készülék a vállalat tulajdonában van, nem ad választ minden engedélyezési kérdésre. A biztonsági, informatikai, adatvédelmi, HR, jogi és munkavállalói képviselőknek esetleg meg kell állapodniuk abban, hogy kik tartoznak a program hatálya alá, hogyan tájékoztatják a munkavállalókat, és mely eredmények láthatók a vezetők számára. A követelmények szervezetenként és joghatóságonként eltérőek.

A beszerzés vagy a kísérleti program megkezdése előtt dokumentálja:

melyik kezelt eszközcsoportok jogosultak a programban való részvételre;
melyik rendszer a hiteles forrás az üzleti telefonszámok tekintetében;
ki hagyja jóvá a tesztet és a címzettek listáját;
mely szerepkörök, régiók, szabadságállapotok vagy érzékeny csoportok vannak kizárva;
van-e külön feltétel a szerződéses és ideiglenes munkatársakra vonatkozóan;
hogyan javíthatják ki az alkalmazottak az elavult vagy átadott számokat; és
milyen gyorsan kerül eltávolításra egy szám az eszköz visszaszolgáltatása vagy a munkavállaló távozása után.

Ne használja fel más célra a HR-nyilvántartásokban szereplő vészhelyzeti kapcsolattartási számokat vagy személyes telefonszámokat. A platformnak kizárólag a jóváhagyott üzleti kapcsolattartási adatokat szabad importálnia, és egyértelmű nyilvántartást kell vezetnie a bevonási és kizárási döntésekről.

Hasonlítsa össze a kezelt eszközök integrációját a túlzott adatgyűjtés nélkül

Egy SMS-es adathalász platformnak ritkán van szüksége széles körű hozzáférésre a mobil eszközhöz. Szüksége van egy jóváhagyott telefonszámra, a tanulási esemény hozzárendeléséhez elegendő azonosító adatra, valamint egy korlátozott körű kézbesítési és válaszadási eseménykészletre. A mobilkészülék-kezelésnek továbbra is a készüléknyilvántartás és a szabályoknak való megfelelés felügyeletét kell ellátnia, nem pedig ürügyül szolgálnia további viselkedési adatok gyűjtésére.

Kérje meg a szolgáltatókat, hogy mutassák be a következőket:

a jogosult telefonszámok ellenőrzött szinkronizálását vagy importálását;
az üzleti számok elkülönítését a személyes kapcsolattartási adatoktól;
a számváltozások, az újbóli hozzárendelés és az ismétlődő rekordok érvényesítését;
a mobil azonosítókhoz és eredményekhez való szerepkörön alapuló hozzáférés;
konfigurálható adatmegőrzés és -törlés;
ellenőrzési naplófájlok az importokról, kampányjóváhagyásokról, exportokról és adminisztratív változtatásokról; valamint
a program futtatásának módja anélkül, hogy a gyakorlattal összefüggésbe nem hozható alkalmazotti SMS-tartalmakat, névjegyeket, alkalmazásadatokat vagy eszköz-telemetriai adatokat olvasná el.

A legbiztonságosabb integráció szűk körű és átlátható. A szolgáltatónak képesnek kell lennie arra, hogy meghatározza, mely adatmezőket kapja meg, miért szükséges az egyes mezők, hol történik az adatok feldolgozása, mennyi ideig tárolják azokat, és hogyan ellenőrzik a törlést.

A kézbesítés tesztelése mint működési függőség

Az SMS-kézbesítés eltér a vállalati e-mailektől. A szolgáltatók, az országok, a feladó típusai, a szűrés, a készülékbeállítások, a roaming és a számváltozások mind befolyásolhatják, hogy egy üzenet megérkezik-e és hogyan jelenik meg. A kézbesítési eredményeket ezért külön kell validálni, mielőtt a munkavállalók viselkedését értelmezni lehetne.

Egy korlátozott technikai teszt során ellenőrizze:

a támogatott országokat, szolgáltatókat és feladóformátumokat;
hogyan jelenik meg a feladó azonosítója a vizsgált, felügyelt iOS- és Android-konfigurációkban;
hogyan jelennek meg a késleltetett, blokkolt, duplikált vagy sikertelen üzenetek;
hogy a szolgáltatói vagy távközlési követelmények előírnak-e kötelező szöveget vagy leiratkozási lehetőséget;
hogy a platform képes-e azonnal leállítani a tesztet;
hogyan befolyásolják az eseményeket a biztonsági szkennerek, a link-előnézetek és a mobilvédelmi eszközök; valamint
hogy a kézbesítési nyilvántartások összehangolhatók-e anélkül, hogy a rutinjelentésekben a teljes telefonszámok nyilvánosságra kerülnének.

Ne kérje meg a szolgáltatót, hogy kerülje meg a szolgáltatói védelmi intézkedéseket, vagy álcázza a forgalmat. Ha egy teszt a védelmi intézkedések megkerülésén alapul, az nem alkalmas tudatosságnövelő gyakorlatnak.

Gondoskodjon olyan mobil bejelentési csatornáról, amelyet a munkavállalók használni tudnak

Az e-mailes bejelentő gombok nem oldják meg az SMS-es bejelentés problémáját. A munkavállalókat felkérhetik arra, hogy továbbítsanak egy üzenetet, készítsenek képernyőképet, nyissanak meg egy szolgáltatási portált, hívják fel a helpdesket, vagy használjanak egy mobilbiztonsági alkalmazást. Minden módszer különböző felhasználhatósági és adatvédelmi kompromisszumokkal jár.

A szimuláció elküldése előtt határozzon meg egy elsődleges bejelentési útvonalat és egy tartalékot. Ezután tesztelje a teljes folyamatot:

Az alkalmazott egy támogatott, felügyelt telefonról jelenti a gyanús SMS-t.
A bejelentés eljut a megfelelő SOC-ba vagy ügyfélszolgálati várólistára.
Az elemzők képesek megkülönböztetni a szimulációs bejelentést a valódi incidensektől anélkül, hogy bármelyiket is figyelmen kívül hagynák.
Az alkalmazott visszaigazolást és biztonságos további lépésekre vonatkozó útmutatást kap.
A képzési platform pontosan rögzíti a bejelentést.
A szervezet továbbíthatja a gyakorlat során felfedezett valódi mobilfenyegetést.

A képernyőképek és a továbbított üzenetek tartalmazhatnak a témához nem kapcsolódó értesítéseket, névjegyeket vagy egyéb kontextust. A jelentési folyamatnak tájékoztatnia kell a munkavállalókat arról, hogyan minimalizálhatják a felesleges adatokat, és nem szabad megkövetelnie tőlük, hogy üzleti tartalmat küldjenek személyes fiókjukon keresztül.

Szigorú biztonsági ellenőrzések bevezetése minden szimulációhoz

A felügyelt telefon továbbra is a munkavállaló számára készült eszköz, és az SMS személyesebbnek és sürgősebbnek tűnhet, mint az e-mail. A forgatókönyvek szabályozásának ezért láthatónak kell lennie a termékben, nem pedig informális ígéretre kell hagyatkozni.

Olyan ellenőrzéseket kell előírni, amelyek megakadályozzák:

valódi jelszavak, MFA-kódok, fizetési adatok, tokenek vagy személyes adatok gyűjtését;
ellenőrizetlen harmadik fél webhelyeire mutató linkeket;
alkalmazások telepítésére vagy az eszköz biztonságának gyengítésére irányuló kérések;
valódi vezetők vagy kollégák személyazonosságának felvétele kifejezett jóváhagyás nélkül;
egészségügyi problémákkal, létszámleépítéssel, bevándorlással, vészhelyzetekkel vagy személyes pénzügyekkel kapcsolatos, nagy szorongást kiváltó témák;
büntető jellegű ranglisták vagy egyének nyilvános azonosítása; valamint
jóváhagyási jogosultsággal nem rendelkező rendszergazdák általi ellenőrizetlen szerkesztés vagy indítás.

A céloldalnak egy jóváhagyott HTTPS-oldalnak kell lennie, amely csak a tanulási cél eléréséhez szükséges minimális eseményeket rögzíti, majd azonnali oktatási visszajelzést ad. A biztonságos, mobilkészülékekre fókuszáló szimulációs funkciók áttekintéséhez lásd az AutoPhish smishing platformot.

Értékelje a visszajelzéseket azon az eszközön, amelyet a munkavállalók ténylegesen használnak

A tanulási pillanatnak a felügyelt mobiltelefonon is működnie kell, nem csupán egy asztali irányítópulton. Kérje meg, hogy láthassa a teljes munkavállalói élményt a támogatott iOS- és Android-konfigurációkon.

A jó visszajelzésnek:

magyaráznia kell a forgatókönyvhöz kapcsolódó figyelmeztető jeleket;
megerősítenie kell a jóváhagyott ellenőrzési és bejelentési útvonalakat;
kerülnie kell a megszégyenítő nyelvhasználatot;
kis képernyőn is hozzáférhetőnek kell lennie;
támogatnia kell a munkaerő által használt nyelveket;
biztonságos következő lépést kell biztosítania mind a bejelentés, mind a kockázatos interakció után; és
kerülnie kell a személyes adatok újabb körének gyűjtését.

Az utólagos képzésnek arányosnak kell lennie a megfigyelt viselkedéssel. Egyetlen interakció után elegendő lehet egy rövid emlékeztető, míg az ismételt kockázatos cselekedetek további coachingot indokolhatnak. A rendszernek támogatnia kell a kivételeket, a szabadságokat, az akadálymentességi igényeket és a befejezési határidőket, amelyeket az adminisztrátorok elmagyarázhatnak.

Használjon olyan mutatókat, amelyek kiállják a technikai vizsgálat próbáját

A nyers kattintási arány különösen megbízhatatlan mobil eszközökön. A link-előnézeti szolgáltatások, a biztonsági eszközök, a véletlen érintések, a késleltetett üzenetek és az újrahasznosított számok mind torzíthatják az eredményeket.

Használjon kiegyensúlyozott mutatókészletet:

jogosult címzettek, kézbesítési kísérletek, megerősített kézbesítések és sikertelen kézbesítések;
a bejelentési arány és a bejelentésig eltelt idő mediánja;
a jóváhagyott bejelentési csatorna helyes használata;
a bejelentések és a kockázatos cselekvések aránya;
az összehasonlítható gyakorlatok során megfigyelt ismétlődő viselkedés;
a nyomon követés befejezése és a későbbi viselkedés; valamint
a szkennelés, előnézet, teszt vagy adminisztratív tevékenységként kizárt események.

A kísérleti program megkezdése előtt dokumentálja az eseménydefiníciókat. A beszerzőknek meg kell kérniük a szolgáltatót, hogy mutassa be, hogyan jelennek meg az SMS-kézbesítés, az oldalbetöltés, a munkavállalói interakció, az automatizált ellenőrzés, a jelentés és a képzés befejezése mind a vezérlőpulton, mind az exportált adatokban.

A NIST iránymutatása a kiberbiztonsági és adatvédelmi képzési programok kidolgozásához támogatja a szerepkörökre szabott, mérhető és folyamatosan fejlesztett képzési programot. Ez egy hatékonyabb modell, mint egy smishing-kattintási arányt ábrázoló diagramot az alkalmazottak kockázatának bizonyítékaként kezelni.

Vezessen be egy felügyelt telefonokra vonatkozó kísérleti programot a szélesebb körű bevezetés előtt

Egy kis léptékű kísérleti programnak az operációs rendszert kell tesztelnie a szimuláció keretében, nem csupán az üzenetet.

Válasszon ki egy reprezentatív csoportot. Válasszon ki korlátozott számú, kezelhető iOS- és Android-eszközt, szolgáltatót, szerepkört és régiót.
Ellenőrizze a címzetteket. Győződjön meg arról, hogy minden üzleti telefonszám aktuális, engedélyezett és a kívánt munkavállalóhoz van rendelve.
Ellenőrizze a kézbesítést és az automatizálásból származó zavarokat. Rögzítse a hibákat, késéseket, előnézeti eseményeket és a biztonsági eszközök tevékenységét.
Gyakorolja be a jelentési munkafolyamatot. Ellenőrizze az alkalmazott visszaigazolását, a SOC- vagy helpdesk-várólistát, az eskalációs útvonalat és a műszerfalon megjelenő eseményt.
Válasszon egy kevésbé drámai célt. Teszteljen egy hitelesítési vagy jelentési folyamatot anélkül, hogy titkos adatokat kérne vagy aktív incidenst másolna.
Ellenőrizze az adatvédelmet és a hozzáférést. Ellenőrizze, mely azonosítók jelennek meg a műszerfalakon, az exportált adatokban, a jegyekben és a tanulási nyilvántartásokban.
Egyeztesse a végleges bizonyítékokat. Hasonlítsa össze a jogosultságot, a kézbesítést, a munkavállalói műveleteket, a jelentéseket, a kizárt automatizált eseményeket és a nyomonkövetési feladatokat.

A kísérleti programnak egy döntéssel kell zárulnia: készen áll a kiterjesztésre, kijelölt javítások után lesz készen, vagy nem alkalmas a tervezett programra. A sikeres elküldés önmagában nem minősül elfogadási kritériumnak.

Tegye fel ezeket a beszerzői kérdéseket a szállítóknak

Konkrét bemutatókat kérjen a funkciólistás válaszok helyett:

Hogyan importálhatók, frissíthetők, kizárhatók és törölhetők a jóváhagyott üzleti telefonszámok?
Mely országokat, szolgáltatókat, feladóformátumokat, iOS-verziókat és Android-verziókat támogatja a rendszer?
Hogyan különbözteti meg a platform az alkalmazottak műveleteit a linkek előnézeteitől és a biztonsági szkennerektől?
A szimulációk jelszavak, MFA-kódok, fizetési adatok vagy egyéb titkos információk gyűjtése nélkül is működhetnek?
Mely mobil jelentési csatornák támogatottak, és hogyan kerülnek a jelentések a SOC-unkba vagy a helpdesk-munkafolyamatunkba?
Mit lát az alkalmazott, miután jelentést tett vagy interakcióba lépett egy felügyelt telefonon?
Mely egyéni azonosítókat tárolják, hol, mennyi ideig, és ki férhet hozzájuk?
Bevezethetnek-e a rendszergazdák jóváhagyási követelményeket, kizárásokat, hatókörrel rendelkező szerepköröket, adatmegőrzési korlátokat és ellenőrzési naplókat?
Hogyan jelennek meg a jelentésekben a sikertelen, késleltetett, duplikált vagy blokkolt üzenetek?
Az exportált adatok összehangolják-e a jogosultságot, a kézbesítést, a viselkedést, a jelentéstételt és a nyomon követést anélkül, hogy túlzottan felnagyítanák a hatékonyságot?

A megfelelő platformnak láthatóvá kell tennie a kivételeket és a hibákat. Egy kifinomult sablonkönyvtár nem pótolhatja az elavult telefonadatokat, a gyenge jogosultságkezelést, a használhatatlan jelentéseket vagy az automatizált eszközök által szennyezett mutatókat.

Hozzon létre egy olyan felügyelt mobilprogramot, amelyben a munkavállalók megbízhatnak

A munkavállalók számára készült hatékony SMS-adathalász-teszt ötvözi az engedélyezett címzetteket, a szűk körű adatfelhasználást, az átlátható kézbesítést, a biztonságos forgatókönyveket, a gyakorlatias jelentéseket, az azonnali tanulást és a megalapozott mérést. A vállalat által kezelt telefonok megkönnyíthetik a program működtetését, de csak akkor, ha a platform kifejezetten támogatja ezeket az ellenőrzési mechanizmusokat.

Ha ellenőrzött smishing-szimulációkat és alkalmazotti jelentési munkafolyamatokat szeretne értékelni, regisztráljon, hogy bevonja az AutoPhish-t a kezelt telefonokra vonatkozó kísérleti programjába.

Gyakran feltett kérdések

Végrehajthat-e egy munkáltató smishing-tesztet egy vállalati telefonon?

Az eszköz tulajdonjoga önmagában nem elegendő jóváhagyás. A szervezetnek meg kell határoznia a célt, a résztvevők körét, a címzettek adatforrását, a munkavállalók számára biztosítandó átláthatóságot, az eredményekhez való hozzáférést, az adatok megőrzését, a kizárásokat, valamint a joghatóságában szükséges érdekelt felek jóváhagyásait.

Kell-e hitelesítő adatokat gyűjtenie egy SMS-es adathalász-tesztnek?

Nem. Egy védelmi tudatosságot fejlesztő gyakorlat képes mérni a biztonságos interakciót, az azonosítást, a jelentéstételt és a nyomon követést anélkül, hogy valódi jelszavakat, MFA-kódokat, fizetési adatokat vagy egyéb titkos információkat tárolna.

Mi a legjobb mutató az alkalmazottak smishing-tesztjeihez?

Egyetlen mutató sem elegendő. A bejelentési arány, a bejelentésig eltelt idő, a helyes bejelentési útvonal, az ismétlődő viselkedés, a kézbesítés minősége és a nyomon követés eredményei együttesen hasznosabbak, mint pusztán a kattintási arány.

A vállalat által kezelt telefonok könnyebben tesztelhetők, mint a BYOD-eszközök?

Ezeknél általában egyértelműbbek az eszköz tulajdonjoga, konfigurációja és a támogatás határai. Ugyanakkor itt is szükség van a jóváhagyott számhasználatra, az adatvédelmi korlátozásokra, a szolgáltató-ellenőrzésre, a biztonságos forgatókönyvekre, a működőképes jelentési rendszerre és a pontos eseménykezelésre.

SMS-phishing-teszt alkalmazottak számára: ellenőrzőlista a kezelt telefonokhoz