Adathalászat-ellenes biztonságtudatossági képzés IT helpdeskek

Az adathalászat-tudatosság az IT help desk számára olyan döntéseket kell, hogy védjen, amelyek megváltoztathatják a fiókhozzáférést. Az általános munkavállalóknak fel kell ismerniük és jelenteniük kell a gyanús kéréseket; a support elemzőknek pedig azonosítást kell ellenőrizniük, mielőtt jelszót állítanak vissza, hitelesítő alkalmazást cserélnek, helyreállítási módszert módosítanak, fiókadatokat adnak ki, vagy jogosultságot emelnek. A vásárlóknak ezért azokat a nagy hatású munkafolyamatokat kell összevetniük a képzési platformokkal — nem csupán az e-mailes kattintási arányokat.

A központi kérdés az, hogy a képzés segít-e az elemzőknek megbízható folyamatot követni akkor, amikor egy meggyőző kérő sürgető helyzetet teremt, azt állítja, hogy kizárta magát, vagy az e-mail, csevegés, telefon, SMS és jegy között mozgatja a beszélgetést. Egy használható program rövid, szerepkör-specifikus tanulást, kontrollált szimulációkat, jóváhagyott ellenőrzési lépéseket, könnyű eszkalációt és bizonyítékot egyesít arra, hogy a folyamat nyomás alatt is helytállt.

Ez az útmutató védekező célú. Nem tartalmaz megszemélyesítési forgatókönyveket, fedősztorikat, hitelesítésmegkerülési lépéseket, hitelesítőadat-gyűjtési módszereket vagy jogosulatlan tesztelésre vonatkozó utasításokat.

Miért van a support csapatoknak másfajta képzési modellre szükségük

A help desk munkatársai nem egyszerűen még egy címzettcsoport. Lehet, hogy képesek hitelesítő adatokat visszaállítani, ideiglenes hozzáférést kiadni, MFA-regisztrációt módosítani, fiókokat feloldani, felhasználóneveket kiadni, kapcsolattartási adatokat frissíteni, vagy kéréseket továbbítani kiemelt jogosultságú adminisztrátorokhoz. Még akkor is, ha minden egyes művelet korlátozott, több apró kivétel összeadódva fiókátvételhez vezethet.

Ezért a folyamatkövetés a tanulási cél. Egy elemző, aki felismeri a gyanús megfogalmazást, de mégis végrehajt egy ellenőrizetlen visszaállítást, nem ért el biztonságos eredményt. Ezzel szemben az az elemző, aki egy udvarias, jól megfogalmazott kérést rutinfeladatként kezel, de követi az előírt ellenőrzési és jóváhagyási utat, a megfelelő kontrollt alkalmazta.

Az US Cybersecurity and Infrastructure Security Agency a Scattered Spider advisory dokumentumban leírja, hogyan használtak fenyegető szereplők ismételt social engineering hívásokat arra, hogy help desk munkatársakat jelszavak vagy MFA tokenek visszaállítására vegyenek rá. A gyakorlati tanulság nem az, hogy megtanítsuk a személyzetnek a támadói kifejezések katalógusát. Hanem az, hogy az érzékeny support műveletekhez olyan ellenőrzés legyen szükséges, amelyet a kérő sem sürgetéssel, sem bizalmaskodással nem írhat felül.

Térképezze fel azokat a műveleteket, amelyeket a képzésnek védenie kell

A kiindulópont a support-katalógus legyen, ne a forgatókönyvtár. Vegye számba azokat a műveleteket, amelyeket az elemző végrehajthat, és mindegyikhez rendeljen kockázati szintet.

A nagy hatású műveletek jellemzően a következők:

jelszó- és passkey-helyreállítás;
MFA-regisztráció, csere vagy eltávolítás;
fiókfeloldások és helyreállítási kapcsolattartó módosítások;
eszközregisztráció és endpoint management kivételek;
hozzáférési csoport, postaláda, szerepkör vagy jogosultság módosítások;
távoli support munkamenetek és szoftverterjesztés;
fiók-, eszköz- vagy munkavállalói információk kiadása; és
eszkaláció olyan csapatok felé, amelyek szélesebb adminisztratív jogosultságokkal rendelkeznek.

Minden érzékeny művelethez dokumentálja a hiteles kérési csatornát, a szükséges bizonyítékot, a független ellenőrzési módszert, a jóváhagyási követelményeket, a tiltott kerülőutakat és az eszkalációs útvonalat. Az olyan megosztott tudás, mint a dolgozói azonosító, a vezető neve, egy friss jegy vagy egy nyilvános életrajzi részlet, nem válhat az identitás bizonyítékává csak azért, mert specifikusnak hangzik.

A térképbe vonja be a kiszervezett vagy követett napos service deskeket is. Ami a központi iroda munkaidejében működik, az megbukhat, amikor az identity csapat nem elérhető, helyi nyelvre van szükség, vagy a kérés beszállítói határokon lép át. A képzésnek ezeket az operatív réseket is fel kell tárnia anélkül, hogy kerülőmegoldások kitalálására ösztönözné az elemzőket.

Állítsa fel az ellenőrzött folyamatot, mielőtt szimulálja

Szimulációval nem lehet tisztességesen mérni olyan viselkedést, amely nincs meghatározva, tanítva és lehetővé téve. Tesztelés előtt járja végig az összes magas kockázatú support műveletet a szolgáltatásgazdákkal, identity adminisztrátorokkal, security operationsszel, HR-rel, adatvédelemmel és — ahol releváns — a support szolgáltatóval együtt.

Az operatív folyamatnak ezekre kell választ adnia:

Melyik rendszer az igazság forrása a kérő identitását és foglalkoztatási státuszát illetően?
Mely ellenőrzési módszerek engedélyezettek az egyes műveletekhez?
Mikor kell az elemzőnek független visszahívást vagy megbízható könyvtári csatornát használnia?
Mely műveletekhez kell második személy vagy kiemelt csapat jóváhagyása?
Mi történjen, ha a szokásos ellenőrzési módszer nem elérhető?
Hogyan tud egy elemző biztonságosan szüneteltetni vagy elutasítani úgy, hogy ne sérüljön a szolgáltatási cél?
Hol jelentik és követik nyomon a gyanús social engineering kísérleteket?

Kerülje azokat az eljárásokat, amelyek a biztonságos viselkedést büntetik. Ha egy elemző teljesítményponthoz kötötten veszít pontot amiatt, hogy egy bizonytalan visszaállítást eszkalál, a képzés a szolgáltatásmenedzsment-rendszerrel fog versenyezni. Hangolja össze a minőségellenőrzést, a szolgáltatási szintcélokat és a vezetői elvárásokat úgy, hogy az ellenőrzés és az eszkaláció sikeres munkának számítson.

A szélesebb employee phishing-awareness buyer guide bemutatja, hogyan illeszkedik össze a tanulás, a biztonságos gyakorlás, a jelentés és az irányítás. Egy service desk esetében ezeknek az elemeknek közvetlenül kell kapcsolódniuk az elemzők által már használt jegy- és identity munkafolyamatokhoz.

Tanítson meg egy ismételhető ellenőrzési mintát

A help desk képzésnek egy rövid mintát kell adnia az elemzőknek, amelyet csatornákon és kéréstípusokon át is alkalmazni tudnak:

Sorolja be a műveletet. Határozza meg, milyen hozzáférés, identitás, adat vagy eszközállapot változna meg.
A jóváhagyott rekordot használja. A megbízható jegy-, könyvtár-, identity- vagy eszközrendszerből induljon ki, ne a kérő által megadott részletekből.
Ellenőrizzen függetlenül. Az adott művelethez előírt módszert használja; ne hagyja, hogy a kérő gyengébb helyettesítőt válasszon.
Érvényesítse a jóváhagyásokat. Szerezze be a második ellenőrzést, ahol azt a szabályzat megköveteli, és őrizze meg a feladatok szétválasztását.
Rögzítse a döntést. Dokumentálja az ellenőrzés és a jóváhagyás eredményét anélkül, hogy titkokat vagy túlzott mennyiségű személyes adatot tárolna.
Eszkalálja az anomáliákat. A gyanús vagy blokkolt kéréseket a meghatározott security útvonalra küldje, és mondja el a kérőnek, mi a legális következő lépés.

Ennek a modellnek működnie kell akkor is, amikor az első kapcsolat e-mailben, csevegésben, telefonon, SMS-ben, önkiszolgáló portálon vagy más support soron érkezik. A csatornaváltás nem törölheti el az eredeti kockázatot. Ha a kérő csevegésben kezdi, majd telefonál, az elemzőnek továbbra is látnia kell vagy hivatkoznia kell a megbízható esetrekordra, és ugyanazt a műveletspecifikus sztenderdet kell alkalmaznia.

A humán segítséggel végzett helyreállítás különös körültekintést igényel. A NIST a Digital Identity Guidelines security considerations dokumentumban megjegyzi, hogy a social engineering ott jelent kockázatot, ahol a hitelesítő helyreállítás emberi segítségre támaszkodik. A vásárlóknak olyan képzést kell keresniük, amely megerősíti a szervezet helyreállítási kontrolljait, nem pedig intuícióval helyettesíti azokat.

Olyan szimulációkat tervezzen, amelyek nem változtathatják meg a valós hozzáférést

A biztonságos help desk gyakorlatoknak a döntéseket kell tesztelniük anélkül, hogy valódi helyreállítási eseményt hoznának létre, vagy a személyzetet a prod kontrollok megkerülésére ösztönöznék. Használjon szintetikus identitásokat, sandboxolt jegyeket, egyértelműen behatárolt munkafolyamatokat és előre jóváhagyott megállási pontokat, ahol csak lehetséges.

Ezeket a védelmi intézkedéseket a kezdés előtt állítsa be:

írásos engedély, megnevezett tulajdonosok és meghatározott support-populáció;
jelszavak, MFA kódok, helyreállítási válaszok, tokenek vagy személyes dokumentumok gyűjtésének tilalma;
valódi jelszó-visszaállítás, hitelesítőcsere, jogosultságadás vagy távoli support munkamenet tilalma;
a security eszközök, audit naplózás vagy identity kontrollok letiltásának tilalma;
valós vezető, kolléga, ügyfél vagy beszállító megszemélyesítése kifejezett jóváhagyás nélkül tilos;
nincs magas érzelmi terhelésű téma, például egészség, felmondás, bevándorlás vagy személyes pénzügyek;
azonnali leállító mechanizmus és egy út a gyakorlat során feltárt valódi incidensek kezelésére;
előzetes egyeztetés az esetlegesen eszkalációt fogadó vezetőkkel és security csapatokkal.

Határozza meg pontosan, mikor ér véget a szimuláció. Ha a cél annak tesztelése, hogy az elemző kér-e független ellenőrzést, a gyakorlatnak akkor kell leállnia, amikor ez a döntés rögzítésre került. Nincs tanulási hozadéka annak, ha a résztvevőt egy prod változás felé terelik, miután a releváns kontrollt már megmérték.

Ne pontozza titokban az elemzőket olyan információk alapján, amelyekhez nem férhetnek hozzá. Ha a szimuláció megbízható könyvtári mezőre, jóváhagyási sorra, visszahívási számra vagy security eszkalációs útvonalra épít, ellenőrizze, hogy a résztvevő a tesztablak alatt használni is tudja ezeket.

Fedje le a teljes support utat

Az e-mail-alapú tesztelés a service desk probléma jelentős részét kihagyja. A programnak azt is értékelnie kell, hogyan halad át egy kérés az intake, triage, ellenőrzés, végrehajtás, dokumentálás, eszkaláció és lezárás fázisain.

Egy behatárolt gyakorlat egy vagy több ilyen kontrollpontot tesztelhet:

felismeri-e az elemző a váratlan visszaállítási kérelmet nagy hatásúként;
az elemző megnyitja-e vagy frissíti-e a megfelelő megbízható jegyet;
az identitás a szükséges módszerrel kerül-e ellenőrzésre;
a csatornaváltás megőrzi-e az ellenőrzési követelményt;
a kivételek megkapják-e a szükséges jóváhagyást;
az elemző megtagadja-e a titkok vagy szükségtelen dokumentumok átvételét;
a gyanús kontextus eljut-e a securityhez használható bizonyítékkal; és
a kérő biztonságos, következetes következő lépést kap-e.

Tartsa fókuszban az egyes gyakorlatokat. Egy összetett, egyszerre e-mailkezelést, hangalapú ellenőrzést, jegyirányítást, MFA-helyreállítást és incidenseszkalációt tesztelő sorozat nehezen diagnosztizálhatóvá teszi a hibákat. Először egyetlen kontrollcélt teszteljen, javítsa ki a munkafolyamatot, és csak ezután kombinálja a csatornákat.

A kontroll teljesítményét mérje, ne az elemző megszégyenítését

A kattintási arány gyenge elsődleges mutató egy olyan csapatnál, ahol a legfontosabb eredmények a kapcsolatfelvétel után következnek be. Definiálja a mérőszámokat a védett művelet és a jóváhagyott folyamat köré.

Hasznos mérőszámok:

helyesen besorolt érzékeny kérések;
a szükséges ellenőrzés a művelet előtt megtörtént;
a nem ellenőrzött változások megakadályozása;
a kivételek a megfelelő jóváhagyási útra kerültek;
a gyanús kérések jelentése a security felé;
az eszkalációig és visszaigazolásig eltelt medián idő;
a szükséges döntési bizonyítékot tartalmazó jegyek;
ismétlődő folyamatkövetés hasonló gyakorlatok során; és
a nem elérhető eszközök, könyvtárak, jóváhagyók vagy utasítások miatt fellépő munkafolyamat-hibák.

Válassza szét az emberi viselkedést a folyamat rendelkezésre állásától. Egy elemző nem tud független visszahívást végrehajtani, ha a könyvtár elavult, és egy jelentés nem jut el a securityhez, ha a sor rossz helyre van irányítva. Ezek program szintű megállapítások, nem egyéni tudatossági hibák.

Kerülje a nyilvános ranglistákat és az egyszerűsítő „kockázatos munkavállaló” címkéket. Csak akkor közöljön csapatszintű trendeket, ha a mintaméret elég nagy, az eltéréseket privát módon vizsgálja ki, és az egyéni eredményeket csak arányos coaching céljára használja a szervezet bevett irányítási rendje szerint. A role-based phishing simulation guide további kontextust ad ahhoz, hogyan lehet összevetni az eredményeket különböző munkakörök között anélkül, hogy azt feltételeznénk, hogy minden szerepkör ugyanazzal a döntési helyzettel szembesül.

Kapcsolja össze a képzést a technikai identity kontrollokkal

A tudatosság nem helyettesíti a rugalmas helyreállítási tervezést. A képzésnek meg kell erősítenie azokat a technikai és eljárásbeli kontrollokat, amelyek csökkentik egy meggyőző kérés értékét.

Értékelje, hogy az átfogó program támogatja-e a következőket:

phishing-resistant MFA az adminisztrátorok és más nagy hatású fiókok számára;
korlátozott és külön felügyelt visszaállítási jogosultságok;
lépcsőzetes ellenőrzés az érzékeny helyreállítási és hozzáférés-módosításokhoz;
kettős jóváhagyás a magas kockázatú műveletekhez;
riasztások a hitelesítő csere és a helyreállítási kapcsolattartó módosítások esetén;
rövid életű, szorosan korlátozott ideiglenes hozzáférés;
manipulációt jól tűrő auditnaplók, amelyek összekötik a kéréseket, jóváhagyásokat és műveleteket; és
a vészhelyzeti és munkaidőn kívüli kivételek időszakos felülvizsgálata.

Amikor egy szimuláció megmutatja, hogy egy elemző a hívó által közölt tények ellenőrzése után el tudja távolítani az MFA-t, a helyes korrekció nem pusztán egy újabb tanfolyam. A szervezetnek ki kell javítania a helyreállítási tervet, az engedélyezési határt vagy a jóváhagyási munkafolyamatot, majd ellenőriznie kell, hogy a kijavított folyamat működik-e.

Ellenőrizze a jelentéskészítést és az incidenseszkalációt

A support elemzők lehetnek az elsők, akik észrevesznek egy valódi social engineering kampányt. Jelentéseiknek elég strukturáltnak kell lenniük ahhoz, hogy a security operations össze tudja kapcsolni az ismétlődő hívásokat, jegyeket vagy fiók-helyreállítási kísérleteket anélkül, hogy az elemzőket arra kényszerítené, hogy érzékeny adatokat másoljanak egy informális csatornába.

Tesztelje, hogy a munkafolyamat képes-e a következőkre:

megkülönböztetni egy szimulációs jelentést a valódi incidenstől;
megőrizni az eredeti jegy és csatorna kontextusát;
rögzíteni a célzott fiókot és a kért műveletet titkok gyűjtése nélkül;
összekapcsolni a kapcsolódó jelentéseket műszakok, helyszínek és beszállítók között;
értesíteni az identity vagy privileged access tulajdonosokat, ha érzékeny változás történhetett;
visszaigazolni az elemző jelentését és biztonságos lezárási utat biztosítani; és
egy a gyakorlat során feltárt valós fenyegetés eszkalálása.

Legalább egy táblás átadás-átvételt tartson a service desk, az identity csapat és a security operations között, mielőtt élő szimulációkat használna. A cél annak bizonyítása, hogy az óvatos elemző gyorsan támogatást kap, ne pedig az, hogy várakoztassuk, miközben egy szimulált kérő tovább nyomást gyakorol.

Futtasson le egy behatárolt pilotot

Kezdje egy support csoporttal, egy érzékeny művelettel és egy ellenőrzési úttal. Egy gyakorlati pilot sorrend a következő lehet:

Egyeztesse a hatókört. Erősítse meg a résztvevőket, műszakokat, beszállítói határokat, nyelveket és engedélyezett csatornákat.
Figyelje meg a valós folyamatot. Járja végig a műveletet egy tesztidentitással, és rögzítse az eszköz- vagy szabályzathiányokat.
Tanítsa meg a döntési modellt. Magyarázza el a besorolást, a független ellenőrzést, a jóváhagyásokat, a dokumentálást és az eszkalációt.
Érvényesítse a biztonsági határt. Győződjön meg arról, hogy a gyakorlat nem módosíthatja a prod hozzáférést és nem gyűjthet titkokat.
Futtasson le egy visszafogott tesztet. Mérjen egy kontrollcélt, és álljon meg a jóváhagyott ponton.
Gyakorolja az átadást. Ellenőrizze, hogy a jelentések a tervezett módon jutnak-e el a vezetőkhöz, az identity tulajdonosokhoz és a security operationshöz.
Tekintse át a bizonyítékot. Válassza szét az elemzői döntéseket a nem elérhető kontrolloktól, az automatizálástól, az útválasztási hibáktól és az adminisztratív teszttevékenységtől.
Javítson, mielőtt bővít. Ugyanazt a kontrollt ismételje meg a korrekció után, mielőtt csatornákat vagy összetettséget adna hozzá.

Az elfogadási döntésnek egyértelműnek kell lennie: bővítésre kész, a megnevezett javítások után kész, vagy alkalmatlan a tervezett munkafolyamathoz. Egy kézbesített üzenet vagy lezárt hívás nem bizonyítja, hogy a kontrollt jól tesztelték.

Tegye fel a szállítóknak ezeket a vásárlói kérdéseket

Kérjen bemutatót egy valósághű support munkafolyamatra, ne egy általános funkcióbemutatóra:

Tudja-e a platform a service desk szerepköröket, műszakokat, beszállítókat, régiókat és jogosultsági szinteket hiteles identity adatok alapján szegmentálni?
Lehetnek-e a gyakorlatok szintetikus identitásokra építve, és megállhatnak-e még azelőtt, hogy bármely prod fiókot vagy hitelesítőt módosítanának?
Mely e-mail, jegy, chat, telefon és mobil csatornák vonhatók be egyetlen engedélyezett gyakorlatba?
Hogyan rögzítik a jóváhagyási, ellenőrzési, eszkalációs és elutasítási döntéseket?
A mérőszámok meg tudják-e különböztetni a biztonságos folyamatkövetést a kattintásoktól, megnyitásoktól, automatikus szkenneléstől és kézbesítési hibáktól?
Hogyan kerüli el a platform a hitelesítő adatok, helyreállítási válaszok, személyes dokumentumok vagy szükségtelen hívási adatok gyűjtését?
A vezetők át tudják-e tekinteni az eredményeket anélkül, hogy az eredeti egyéni adatokat az engedélyezett közönségen túl is látnák?
Mi történik, ha egy gyakorlat valódi incidens jelentését váltja ki?
Támogatják-e a tartalmak és munkafolyamatok a help desk nyelveit, akadálymentességi igényeit és működési óráit?
Megmutatja-e az audit nyomvonal az engedélyezést, a forgatókönyv-jóváhagyást, a résztvevői hatókört, az indítást, a leállítást, a változásokat és a bizonyítékexportot?

Egy nagy forgatókönyvkatalógus nem ellensúlyozza a gyenge prod határokat, a használhatatlan eszkalációt vagy a visszaállítási és helyreállítási folyamattól elszakadó mérőszámokat.

Gyakran ismételt kérdések

Tartalmaznia kell a help desk adathalászat-képzésnek a telefonos és csevegéses kéréseket is?

Igen, ha ezek a csatornák a valós support folyamat részei, és a gyakorlat engedélyezett és ellenőrzött. Kezdje egy csatornával és egy döntési céllal, majd akkor tesztelje a csatornaátadást, ha az ellenőrzés, a jegykezelés, a jelentés és a biztonsági kontrollok megbízhatóan működnek.

Kérhet-e egy szimuláció egy elemzőt arra, hogy valódi jelszót vagy MFA módszert állítson vissza?

Nem. Használjon szintetikus identitásokat, tesztkörnyezeteket, sandboxolt jegyeket, vagy egy megállási pontot bármilyen prod változtatás előtt. Egy biztonságos gyakorlat képes mérni, hogy az elemző követi-e az ellenőrzési és jóváhagyási követelményeket anélkül, hogy a valós hozzáférést megváltoztatná.

Mi a legjobb mérőszám a service desk tudatossági képzéshez?

Egyetlen mérőszám sem elegendő. Kövesse, hogy a érzékeny műveleteket helyesen sorolták-e be, az identitást a jóváhagyott módszerrel ellenőrizték-e, a nem ellenőrzött változásokat megakadályozták-e, a kivételeket jóváhagyták-e, a gyanús kéréseket eszkalálták-e, és a munkafolyamat-réseket kijavították-e.

Milyen gyakran kell tesztelni az IT support csapatokat?

A gyakoriságnak a kockázathoz, a folyamatváltozáshoz és a bizonyíték minőségéhez kell igazodnia. Teszteljen nagy identity- vagy jegykezelési változások után, amikor új beszállító vagy support-populáció kerül be, és elég rendszeresen ahhoz, hogy megerősítse: a kritikus munkafolyamatok továbbra is működnek. Kerülje a folyamatos meglepetésszerű gyakorlatokat, amelyek aláássák a bizalmat vagy gépies gyanakvásra ösztönöznek.

Kiváltja-e a tudatossági képzés a phishing-resistant MFA-t vagy az erősebb helyreállítási kontrollokat?

Nem. A képzés segít az elemzőknek következetesen alkalmazni a kontrollokat; nem tud kompenzálni egy olyan helyreállítási folyamatot, amely gyenge bizonyítékot fogad el vagy túlzott visszaállítási jogosultságot ad. Használja a szimulációk eredményeit az identity architektúra, a jóváhagyási határok, a naplózás és a helyreállítási terv javítására.

Tegye a biztonságos supportot a legkönnyebb úttá

A hatékony képzés olyan folyamatot ad a help desk elemzőknek, amelyet nyomás alatt is követni tudnak: sorolják be a kért műveletet, használjanak megbízható rekordokat, ellenőrizzenek függetlenül, szerezzék be a szükséges jóváhagyást, dokumentálják a döntést, és eszkalálják az anomáliákat. A legerősebb programok emellett kijavítják azokat az eszközöket és teljesítményösztönzőket is, amelyek az insegurális kerülőutakat csábítóvá teszik.

Ha kontrollált szimulációkat, szerepkör-specifikus tanulást, jelentési munkafolyamatokat és védhető bizonyítékot szeretne értékelni support csapatok és a szélesebb munkavállalói kör számára, Sign Up to include AutoPhish in your pilot.

Adathalászat-ellenes biztonságtudatossági képzés IT helpdeskek számára: Ellenőrzőlista