Smishing-szimulációk a BYOD-hez: Ellenőrzőlista a biztonságos

A BYOD-ra vonatkozó smishing-szimulációknak a vállalat mobil jelentési és ellenőrzési szokásait kell tesztelniük anélkül, hogy a személyes telefonokat felügyelet nélküli megfigyelési célpontokká tennék. Bármilyen szimulált SMS elküldése előtt határozza meg, ki vehet részt, mely számok használhatók, milyen adatokat rögzít a platform, hogyan jelentsék be az alkalmazottak az üzenetet, és hogyan lehet bárkinek leiratkozni vagy felügyelt alternatívát használni. Ha egy szolgáltató nem tudja támogatni ezeket az ellenőrzési mechanizmusokat, akkor nem áll készen egy BYOD-programra.

A beszerzés szempontjából a legfontosabb kérdés nem az, hogy egy platform képes-e szöveges üzeneteket küldeni, hanem az, hogy a biztonsági, IT, adatvédelmi, HR és munkavállalói képviselők biztonságosan tudják-e működtetni a programot mind a személyes, mind a vállalati tulajdonú eszközökön. Egy meggyőző bemutató elrejtheti a nehéz részeket: a hozzájárulási nyilvántartásokat, a számok tulajdonjogát, a szolgáltatók viselkedését, a segítségnyújtó központnak elküldött képernyőképeket, a megőrzési határidőket, valamint azokat a munkavállalókat, akik nem szeretnének képzési üzeneteket kapni a magán telefonjukon.

Ez az útmutató védelmi célú. Nem tartalmaz smishing-sablonokat, hamisításra vonatkozó utasításokat, hitelesítő adatok gyűjtésére szolgáló technikákat, a kézbesítés megkerülésére irányuló taktikákat, illetve útmutatást jogosulatlan teszteléshez.

Döntse el, hogy a BYOD beletartozik-e a hatályba

Ne feltételezze, hogy minden mobilszámmal rendelkező munkavállalónak szimulációt kell kapnia. Kezdje azzal, hogy feltérképezi, hogyan támogatják a mobilkészülékek a tényleges munkavégzést.

Legalább négy csoportot különítsen el:

olyan alkalmazottak, akik vállalati tulajdonú, teljes mértékben felügyelt telefonokkal rendelkeznek
olyan alkalmazottak, akik személyes tulajdonú eszközöket használnak, és hivatalos BYOD-programban vesznek részt
olyan alkalmazottak, akik személyes telefonjaikat kizárólag többfaktoros hitelesítésre (MFA) vagy vészhelyzeti kapcsolattartásra használják
olyan alkalmazottak, akiknek munkakörük nem igényel telefont

Ezek a csoportok nem jelentenek azonos engedélyezési vagy adatvédelmi helyzetet. A vészhelyzetekre a HR-nyilvántartásokban tárolt telefonszám nem minősül automatikusan biztonsági tesztelésre jóváhagyottnak. Hasonlóképpen, a mobilkészülék-kezelési rendszerbe való regisztráció sem feltétlenül jogosít fel szimulált SMS-üzenetek fogadására.

Minden csoport esetében dokumentálni kell a felvétel üzleti indokát, a jóváhagyott kommunikációs csatornát, a telefonszám tulajdonosát, az adatkezelés jogi és szerződéses alapját, valamint azokat az alternatívákat, amelyek azok számára állnak rendelkezésre, akik nem vehetnek részt a programban, vagy nem szabad részt venniük benne. Az adatvédelmi és munkajogi tanácsadóknak ellenőrizniük kell a végleges megközelítést az érintett joghatóságok tekintetében.

Az eredmény egy vegyes program lehet. A kezelt telefonok ellenőrzött szimulációkat kaphatnak, a hivatalos BYOD-résztvevők egyértelmű szabályok szerint csatlakozhatnak, míg mindenki más elvégezheti a mobil adathalászattal kapcsolatos tudatosságnövelő képzést anélkül, hogy személyes eszközén tesztet kapna.

Határozza meg, milyen viselkedést kell javítania a tesztnek

Egy BYOD-smishing-szimulációnak szűk körű viselkedési célra van szüksége. A „nézzük, ki érinti meg” nem elegendő. A linkek előnézetei, a véletlen érintések, a szolgáltatók által végzett szkennelés, a biztonsági szoftverek és a megosztott képernyők mind torzíthatják a kattintási adatokat.

Válasszon ki egy elsődleges kimenetelt, például azt, hogy a munkavállalók:

megállnak-e, és ellenőriznek-e egy váratlan mobilkérést egy jóváhagyott csatornán keresztül
jelentik-e a gyanús SMS-eket a vállalat dokumentált eljárása szerint
elkerülik, hogy érzékeny munkafolyamatot vigyenek át egy felügyelt rendszerből SMS-be
felismerik, hogy a sürgősség, a hatóság és a kényelem nem bizonyítják a legitimitást
tudják, mit kell tenniük, miután kapcsolatba kerültek egy gyanús üzenettel

A bejelentési arány, a bejelentésig eltelt idő, a helyes bejelentési útvonal és a biztonságos utólagos magatartás általában nagyobb operatív értéket nyújt, mint a nyers kattintási arány. Ezek a mutatók azt mutatják, hogy a szervezet képes-e felismerni és kezelni egy valódi mobil adathalász-kísérletet, és nem csupán azt, hogy egy szimulált link eseményt regisztrált-e.

Ha a program az e-mailekre is kiterjed, tartsa következetesnek a tanulási célt, miközben a bejelentési útvonalat a mobil eszközökhöz igazítja. A phishing-képzés kontra phishing-szimuláció című útmutatónk elmagyarázza, miért kell az oktatásnak és a tesztelésnek egymást erősítenie, ahelyett, hogy egymással versengene a figyelemért.

Állítsa be az adatvédelmi és hozzájárulási beállításokat a beszerzés előtt

Az adatvédelmi követelmények meghatározásának legbiztonságosabb ideje a szállítóval végzett kísérleti üzem előtt van. Ellenkező esetben a platform alapértelmezett beállításai válnak a program irányelveivé.

Kérje meg a szolgáltatókat, hogy mutassák be, hogyan kezelik:

a mobilszámokat, beleértve azok forrását, érvényesítését, javítását és törlését
a hozzájárulási vagy részvételi nyilvántartásokat, ahol szükséges
az opt-out és az alternatív képzési munkafolyamatokat
az üzleti és személyes kapcsolattartási adatok szétválasztását
az adatok tárolási helyét, az alvállalkozókat, a megőrzési és törlési ütemterveket
a kampánykezelők, elemzők és ügyfélszolgálati munkatársak hozzáférési ellenőrzései
olyan exportálások, amelyek telefonszámokat vagy egyéni viselkedési mintákat tehetnek közzé
szerepkörön alapuló vagy összesített jelentések vezetők és munkavállalói képviselők számára
azok a munkavállalók, akik kilépnek, telefonszámot váltanak vagy visszaadják a vállalati eszközt

Az adatminimalizálásnak láthatónak kell lennie a termékben. Egy platformnak nem szabad szüksége lennie névjegyzékekre, a munkavállaló beérkező leveleinek tartalmára, személyes alkalmazásadatokra, eszközazonosítókra vagy titkos adatokra ahhoz, hogy biztonságos szimulációt nyújtson. Lehetővé kell tenni továbbá az események gyűjtésének korlátozását a megállapodás szerinti képzési eredmény eléréséhez szükséges minimumra.

A NIST iránymutatása a kiberbiztonsági és adatvédelmi képzési programok kidolgozásáról hasznos hivatkozás ahhoz, hogy a tudatosságot szabályozott, szerepkörökre figyelemmel lévő programként kezeljük, nem pedig egymástól elszigetelt tesztek sorozataként. Ez nem helyettesíti a helyi foglalkoztatási, adatvédelmi vagy távközlési tanácsadást, de szilárd működési alapot biztosít.

Hozzon létre egy olyan mobil bejelentési csatornát, amely a gyakorlatban is működik

Az e-mailes bejelentő gombok nem oldják meg az SMS-es bejelentés problémáját. Egy személyes telefonon az alkalmazottnak lehet, hogy nincs felügyelt biztonsági alkalmazása, nem ismeri a helpdesk számát, és vonakodhat attól, hogy továbbítson egy üzenetet, amely felfedi a magánszámát.

A szimuláció előtt tervezze meg a bejelentési munkafolyamatot:

Tegyen közzé egy könnyen felismerhető bejelentési csatornát a mobil fenyegetések esetére.
Magyarázza el, hogy az alkalmazottaknak továbbítaniuk kell-e az üzenetet, képernyőképet kell-e küldeniük, egy szolgáltatási portált kell-e használniuk, vagy fel kell-e hívniuk a helpdesket.
Határozza meg, milyen személyes adatok jelenhetnek meg egy bejelentésben, és hogyan kell a személyzetnek ezeket minimálisra csökkenteni.
Képezze ki a helpdesket vagy a SOC-ot arra, hogy meg tudják különböztetni a szimulációs bejelentéseket a valódi incidensektől.
Határozza meg a valódi gyanús üzenetek visszaigazolásának és eskalálásának folyamatát.
Tesztelje a munkafolyamatot iOS-en, Androidon, felügyelt eszközökön és legalább egy általános személyes eszközkonfiguráción.

A továbbítások és a képernyőképek tartalmazhatnak nem kapcsolódó értesítéseket, névjegyeket, jelzésadatokat vagy egyéb személyes kontextust. Biztosítson az alkalmazottak számára egy egyszerű jelentési módot anélkül, hogy túl sok információt kellene megosztaniuk. Ha az elemzőknek kampányazonosítóra van szükségük, a platformnak olyat kell biztosítania, amely nem tanítja meg az alkalmazottakat arra, hogy a jövőben figyelmen kívül hagyják a hasonló üzeneteket.

Az első kampány előtt végezzen asztali tesztet a biztonsági, IT-támogatási és adatvédelmi érdekelt felekkel. Egy szimulált bejelentésnek el kell jutnia a megfelelő sorba, gyorsan fel kell ismerni, megfelelő visszaigazolást kell kapnia, és helyesen kell megjelenni a végső bizonyítékok között. Ha ez a folyamat nem működik, javítsa ki, mielőtt bevonná az alkalmazottakat.

Gondoskodjon a szimuláció technikai és pszichológiai biztonságáról

A mobil üzenetek azonnaliaknak és személyesnek tűnnek. Ezért különösen fontos a forgatókönyvek arányos kezelése.

Használjon kitalált, alacsony érzékenységű üzleti kontextust. Ne adja ki magát valódi vezetőknek, családtagoknak, egészségügyi szolgáltatóknak, pénzintézeteknek, sürgősségi szolgálatoknak, illetve folyamatban lévő munkavállalói ügyek szereplőinek. Ne kérjen jelszavakat, MFA-kódokat, fizetési adatokat, személyes adatokat vagy alkalmazás-telepítéseket. A tanulási oldalon el kell magyarázni a releváns figyelmeztető jeleket és a jóváhagyott ellenőrzési folyamatot anélkül, hogy titkos adatokat gyűjtenének.

Kerülje azokat a forgatókönyveket, amelyek kihasználják a szorongást, az egészségügyi aggályokat, a munkahelyi biztonságot, a fegyelmi intézkedéseket, a bevándorlási státuszt vagy a személyes pénzügyi nehézségeket. A realizmus nem feltétlenül jár érzelmi sérelemmel. Egy hasznos szimuláció felismerhető döntési pontot teremt, majd megtanítja a biztonságosabb reagálást.

A testreszabásnak is szüksége van korlátokra. Ha a forgatókönyv rugalmassága része a vásárlási döntésnek, használja ezt a biztonságos, testreszabható smishing-forgatókönyv ellenőrzőlistát az ellenőrzési mechanizmusok, jóváhagyások, regionális adaptáció és a sablonhatárok értékeléséhez.

Ellenőrizze a kézbesítést anélkül, hogy veszélyes kivételeket kérne

Az SMS-kézbesítés nem annyira ellenőrizhető, mint a vállalati e-mail. A szolgáltatók, az aggregátorok, a helyi szabályozások, a feladó típusai és a készülékbeállítások befolyásolhatják, hogy egy üzenet megérkezik-e, illetve hogyan jelenik meg.

Egy korlátozott kísérleti program során ellenőrizze:

mely országokat és szolgáltatókat támogatja a szállító
hogyan jelenik meg a feladó azonosítója a címzettek számára
alkalmazandók-e a leiratkozási feltételek vagy a szolgáltatói szabályok
hogyan befolyásolják a késleltetett vagy sikertelen üzenetek a kampány eredményeit
okoznak-e hamis eseményeket a link-előnézetek vagy a biztonsági szkennerek
hogyan kezelik az újrahasznosított vagy nemrég megváltozott telefonszámokat
képes-e a szolgáltató azonnal leállítani egy kampányt
elkülönítik-e a tesztforgalmat az operatív értesítésektől

Ne kérje a szolgáltatót, hogy kijátsza a szolgáltatói ellenőrzéseket, vagy leplezze el az üzenetek valódi eredetét. A szimulációs platformnak az érvényes üzenetküldési szabályok keretein belül kell működnie, és átlátható kézbesítési nyilvántartásokat kell biztosítania. Ha a hasznos képzés a biztonsági intézkedések megkerülésén múlik, akkor a rendszer kialakítása hibás.

Külön-külön hasonlítsa össze a vállalati és a személyes eszközöket

Az összesített irányítópultok elrejthetik a fontos különbségeket. A kezelt telefonok rendelkezhetnek biztonsági ellenőrzésekkel, jóváhagyott jelentéskészítő alkalmazásokkal és vállalati támogatással. A személyes telefonok eltérő operációs rendszerekkel, akadálymentesítési beállításokkal, nyelvekkel, szolgáltatói funkciókkal és adatvédelmi elvárásokkal rendelkezhetnek.

Ahol a jogi és szervezeti modell megengedi, szegmentálja az eredményeket eszközkezelési csoportok szerint, de kerülje el, hogy a program személyes megfigyeléssé váljon. A cél a munkafolyamatbeli hiányosságok feltárása, nem pedig az egyének rangsorolása.

Egy gyakorlati áttekintés során érdemes összehasonlítani a következőket:

a jóváhagyott eszközcsoportok szerinti sikeres kézbesítési arányok
a jelentési útvonal helyes használata a felügyelt és a személyes telefonokon
a jelentés benyújtásáig eltelt idő mediánja csatornánként
a felesleges személyes adatokat tartalmazó jelentések
a helpdesk kezelési idejét és az események továbbításának pontosságát
a szimulációt követő képzés elvégzését
az ismételt fejlődést csapat- vagy csoportszinten

A technikai zavarokat külön kell dokumentálni. Ha egy mobilbiztonsági termék automatikusan megnyit egy linket, ne rögzítsék ezt az eseményt a munkavállaló hibájaként. A gyártóknak lehetővé kell tenniük a rendszergazdák számára, hogy ezeket az eseteket kijavítsák vagy megjegyzésekkel lássák el anélkül, hogy az eredeti ellenőrzési nyomvonalat átírnák.

Tervezze meg a nyomon követést a részvétel büntetése nélkül

Az azonnali visszajelzésnek rövidnek, mobilbarátnak és a képzés tárgyát képező viselkedéshez kapcsolódónak kell lennie. Magyarázza el, milyen jelzés indokolta az ellenőrzést, hová kell az alkalmazottnak hasonló üzeneteket jelenteni, és mit kell tennie, ha valóban gyanús SMS-t kap.

Ne szégyenítsd meg az alkalmazottakat, és ne hozd nyilvánosságra az egyéni eredményeket széles körű vezetői csoportok előtt. Azok, akik azonnal jelentik az esetet – akár az interakciót követően is –, értékes felderítési időt biztosítanak a biztonsági csapatnak. A programnak a jelentéstételt kell erősítenie, nem pedig arra kell tanítania az alkalmazottakat, hogy elrejtsék a hibáikat.

Csak akkor alkalmazz mélyebb utólagos intézkedéseket, ha azok egy dokumentált kockázati célt szolgálnak. Az első interakció esetén elegendő lehet egy rövid emlékeztető. Az ismétlődő minták szerepkörhöz igazodó coachingot vagy támogató beszélgetést indíthatnak el, de az automatikus eskalációt felül kell vizsgálni a téves riasztások, az akadálymentességi igények, a megosztott eszközök és a technikai tényezők szempontjából.

Használjon ellenőrzött kísérleti ellenőrzőlistát

Mielőtt kiválasztana egy szolgáltatót, vagy egy kis csoporton túlra terjesztené a programot, győződjön meg arról, hogy a szervezet minden pontra igennel tud válaszolni:

A bevont eszközcsoportok és az üzleti cél dokumentálva vannak.
A személyes telefonszámokat nem használják fel más célra, nem kapcsolódó HR-nyilvántartásokból.
Áttekintették az adatvédelmi, munkajogi, távközlési és munkavállalói képviseleti követelményeket.
A résztvevők egyértelmű tájékoztatást kapnak, lehetőségük van az opt-outra, vagy adott esetben kezelhető alternatívájuk van.
A platform minimalizálja a tárolt mobil- és viselkedési adatokat.
Az operátorok nem tekinthetnek meg és nem exportálhatnak több személyes adatot, mint amennyit szerepük megkövetel.
A jelentési munkafolyamat mind a kezelett, mind a személyes telefonokról működik.
A helpdesk vagy a SOC képes azonosítani a szimulációs jelentéseket anélkül, hogy figyelmen kívül hagyná a valódi incidenseket.
A forgatókönyv-korlátok tiltják a titkok, az érzékeny személyes kontextus és a káros nyomásgyakorlási taktikák használatát.
A kézbesítési hibák, az előnézetek és a szkennelési események elkülöníthetők a felhasználói viselkedéstől.
A visszajelzés mobilbarát, és egy konkrét ellenőrzési vagy jelentési lépésre irányít.
A kampány leállítási, törlési és incidenskezelési eljárásait tesztelték.
Az eredmények hasznos kohorszszinten áttekinthetők anélkül, hogy hibáztató irányítópultot hoznának létre.
A kísérleti programnak van felelőse, sikerességi kritériumai, felülvizsgálati dátuma, valamint a befejezés után dokumentált döntés.

Ha több válasz is „nem”, halassza el a BYOD-kampányt. A képzési tartalom továbbra is foglalkozhat a smishinggel, miközben a szervezet rendezni tudja az irányítási és jelentési folyamatokat. Ha először a szimulációt küldik el, az csak az ismert folyamatbeli hiányosságokat alakítja át a munkavállalók zavarába.

GYIK

Végrehajthat-e egy vállalat smishing-szimulációkat személyes telefonokon?

Esetenként igen, de az, hogy a szervezet rendelkezik az alkalmazott telefonszámával, önmagában nem jogosítja fel a tesztelésre. A szervezetnek meg kell határoznia egy érvényes üzleti célt, a részvételi szabályokat, az adatvédelmi ellenőrzéseket, a szükséges esetben a megfelelő értesítést vagy hozzájárulást, az adatmegőrzési határidőket, valamint egy gyakorlati alternatívát. Fontos a helyi jogi és munkavállalói kapcsolatok szempontjából történő felülvizsgálat.

Kell-e a smishing-szimulációnak jelszavakat vagy MFA-kódokat gyűjtenie?

Nem. Egy biztonságos tudatosságnövelő szimuláció a titkos adatok gyűjtése nélkül is képes mérni az üzenet kézbesítését, az interakciót, a jelentéstételt és a képzés elvégzését. A céloldalon megjelenő élménynek a hitelesítésre és a jelentéstételre vonatkozó magatartást kell tanítania.

Mi a legjobb mérőszám egy BYOD-smishing-teszt esetében?

A helyes jelentési magatartás általában hasznosabb, mint pusztán a kattintási arány. Kövesse nyomon, hogy a jelentések eljutnak-e a jóváhagyott csatornára, milyen gyorsan érkeznek meg, az elemzők képesek-e azokat osztályozni, és javul-e a követő magatartás. A technikai előnézeteket és a szkennerek tevékenységét külön rögzítse.

Mi van, ha az alkalmazottak nem szeretnének képzési szövegeket kapni a személyes telefonjaikra?

Biztosítson egy egyértelmű leiratkozási lehetőséget vagy alternatív módszert, amely összhangban áll a szervezet irányelveivel és jogi kötelezettségeivel. A mobil adathalászattal kapcsolatos tudatosságot irányított képzés keretében is meg lehet tanítani anélkül, hogy szimulációt küldenének egy magánkészülékre.

Szükség van-e külön mobil adathalászati képzésre, ha már teszteljük az e-maileket?

Általában igen. A mobil képernyők elrejtik a kontextust, a jelentési útvonalak eltérőek, és az SMS-ek eljuthatnak az alkalmazottakhoz a felügyelt e-mail rendszereken kívül is. A tanulási célkitűzés maradhat ugyanaz, de az ellenőrzések és a válaszadási munkafolyamatok mobil-specifikus tesztelést igényelnek.

Tegye a BYOD-ot irányítási döntéssé, ne pedig küldési funkcióvá

Egy smishing-platform csak akkor alkalmas a BYOD-ra, ha támogatja a világos hatályt, a minimális adatmennyiséget, az alkalmazottak választási lehetőségét, a biztonságos forgatókönyveket, a megbízható jelentéstételt és a megalapozott nyomon követést. A leghatékonyabb program nem az, amelyik a legtöbb SMS-t küldi. Hanem az, amely segít az alkalmazottaknak ellenőrizni a váratlan mobilkéréseket, és olyan jelentési csatornát biztosít a biztonsági csapat számára, amely akkor is működik, amikor valódi üzenet érkezik.

Ha egy biztonságosabb, automatizált tudatosságnövelő platformot értékel, regisztráljon, és tesztelje a működési modellt egy ellenőrzött kísérleti program keretében, mielőtt kiterjesztené a célközönséget.

Smishing-szimulációk a BYOD-hez: Ellenőrzőlista a biztonságos programhoz