Röviden: A biztonságtudatosság a webes csapat munkatársainál azt jelenti: mindenki, aki weboldalt gondoz, ismeri a szerepkörének három-négy kockázatát, felismeri a szokatlan jelenségeket, és gyorsan, szemrehányástól való félelem nélkül jelenti őket. A szerkesztőknek más tartalmakra van szükségük, mint az adminoknak. A rövid, ismétlődő egységek a saját CMS példáival jobban hatnak, mint egy éves kötelező képzés.
Miért éppen most van a középpontban a webes csapat
A PHP2Shell körüli helyzet megmutatta, mennyi minden zúdul néhány nap alatt a weboldalak üzemeltetőire: a BSI (a német Szövetségi Információbiztonsági Hivatal) figyelmeztetései, tárhelyszolgáltatók közleményei, tanácsok fórumokon és közösségi hálózatokon, köztük hamisak is. Ilyen hetekben nemcsak az adminok, hanem a szerkesztők, a marketing és az asszisztensek is döntenek arról, melyik levelet nyitják meg, és melyik linkre kattintanak.
A nagy hírhelyzetek tapasztalat szerint alkalmat jelentenek a csalóknak. Számítson olyan levelekre, amelyek tárhelyszolgáltatónak, CMS-gyártónak vagy „IT-osztálynak” adják ki magukat, és sürgős bejelentkezésre vagy állítólagos biztonsági frissítésre szólítanak fel. Aki ismeri a valós helyzetet, ritkábban ddől be ennek. Magát a műszaki rést egyetlen szerkesztő sem zárja le, de egy ellopott admin-hozzáférés rés nélkül is kinyitja az ajtót.
Biztonságtudatosság a munkatársaknál: ki mire szorul?
Mindenki számára ugyanazokkal a diákkal tartott képzés többnyire célt téveszt. Értelmesebb a szerepkörök szerinti szabás. A következő áttekintés segít a tervezésben:
| Szerepkör | Tipikus kockázatok | Mit kell tudnia a személynek |
|---|---|---|
| Szerkesztő, marketing | adathalász levelek, nem biztonságos fájlfeltöltések, megosztott hozzáférések | ellenőrizni a feladót, csak várt fájltípusokat feltölteni, a saját hozzáférési adatokat soha nem továbbadni |
| CMS-adminisztrátor | ismeretlen forrású bővítmények, túl sok admin-fiók, egykori munkatársak régi fiókjai | takarékosan osztani a jogokat, rendszeresen ellenőrizni a fiókokat, bővítményeket csak jóváhagyással telepíteni |
| Szerver-admin | ellenőrizetlen netes tippek, napló nélküli módosítások, elfelejtett tesztfájlok | értékelni a forrásokat, dokumentálni a módosításokat, ismerni a vészhelyzeti utat |
| Vezetés | nyomás a gyors döntésekre, tisztázatlan illetékességek | rögzíteni a döntési utakat, komolyan venni a jelentéseket, jóváhagyni a megelőzés költségvetését |
| Külső ügynökség | közös hozzáférések, hiányzó megállapodások | saját, személyes fiókokat használni, bejelenteni a módosításokat |
A táblázat azt is mutatja, hol kell segítenie a technikának. A közös hozzáférések helyett személyes fiókok, valamint a kétfaktoros bejelentkezés mindenkinek, aki írási joggal rendelkezik, sok terhet levesz a képzésről. Hogyan megy ez, azt a Kétfaktoros bejelentkezés admin-hozzáférésekhez tartalmazza.
Mit kell tudniuk a szerkesztőknek anélkül, hogy technikussá válnának
A szerkesztőknek nem kell tudniuk, mi az a PHP-worker. Három dolgot azonban biztosan uralniuk kell. Először: a „biztonsági incidens miatti” újbóli bejelentkezésre való felszólítást soha nem a levélben lévő linken keresztül intézik, hanem a megszokott úton a CMS-be, vagy az adminnál való rákérdezéssel.
Másodszor: a szokatlan jelenségek jelentése. Ide tartoznak az ismeretlen felhasználói fiókok a felhasználólistában, olyan oldalak vagy bejegyzések, amelyeket senki sem hozott létre, a hirtelen átirányítások és a figyelmeztetések a böngészőben. Egy szerkesztő gyakran többször látja a weboldalt, mint az admin, és korábban észreveszi a változásokat.
Harmadszor: a feltöltések tudatos kezelése. A képek és PDF-ek mindennaposak, de a szokatlan kiterjesztésű fájl, az „továbbításra” szánt archívum vagy a makrókat tartalmazó dokumentum nem való a CMS-be. Ha egy fájlt nem lehet feltölteni, az többnyire szándékos, és nem olyan hiba, amelyet meg kellene kerülni.
Mire van még szükségük az adminoknak
Az adminoknál kevésbé az adathalászatról van szó, mint az időnyomás alatti ítélőképességről. A PHP2Shell hetében olyan tanácsok keringtek, amelyeket a szakmai szerzők kifejezetten elutasítanak, például az összes PHPSESSID-t tartalmazó kérés blokkolását. Az ilyen tévutak áttekintését nyújtja a Veszélyes téves tippek a PHP2Shellről cikk. A jó adminok először az elsődleges forrást ellenőrzik, vagyis a php.netet, a BSI-t vagy a gyártót, mielőtt egy konfigurációt módosítanak.
Ide tartozik a fegyelem a módosításoknál: mit változtattak mikor és miért, és hogyan lehet visszavonni? Egy rövid bejegyzés a ticketben vagy a wikiben elég. Éles helyzetben ez a lista aranyat ér, mert megmutatja, melyik módosítás származik Öntől, és melyik nem.
Végül az adminoknak tudniuk kell, miről ismerik fel egy lehetséges behatolást, és mit nem szabad ilyenkor tenni: nem szabad kapkodva törölni, nem szabad azonnal újratelepíteni, hanem rögzíteni és jelenteni kell. A tipikus jeleket a Feltörték már a rendszeremet? foglalja össze.
90 nap alatt éber webes csapat
Egy programnak nem kell nagynak lennie ahhoz, hogy hasson. Ezek a lépések váltak be:
- Az állapot tisztázása (1-2. hét): Kinek milyen hozzáférései vannak a CMS-hez, a tárhelyhez, a domainhez és a szerverhez? A közös fiókokat fel kell oldani, a régi fiókokat le kell zárni.
- A jelentési út rögzítése (2. hét): Egy cím vagy csatorna a „valami furcsának tűnik” esetekre. Minden jelentésre válaszolnak, akkor is, ha ártalmatlan volt.
- Az első rövid egység szerepkörönként (3-4. hét): 20 perc, példák a saját CMS-ből, valódi menük képernyőfotóival.
- Kétfaktoros bejelentkezés bevezetése (a 6. hétig): Mindenkinek, aki írási joggal rendelkezik, a vészkódokat biztonságos helyen tárolva.
- Gyakorló levél és kiértékelés (8. hét): Egy bejelentett tesztkampány az egyes személyek lejáratása nélkül. Azt értékelik ki, hogy jelentettek-e, nem azt, hogy ki kattintott.
- Második egység egy aktuális alkalomhoz (10-12. hét): Például egy aktuális biztonsági helyzet, a saját rendszeren végigjátszva.
A sikert a jelentésekkel mérje, ne a kattintási arányokkal. Az a csapat, amely sokat jelent, éber. Az a csapat, amely soha nem jelent, vagy tökéletes, vagy bizonytalan, és az előbbi ritka.
Hogyan segít konkrétan a PHP SOS?
- Önnel együtt felmérjük, kinek milyen hozzáférései vannak, és megmutatjuk a közös fiókokat, a felesleges adminokat és az elfelejtett hozzáféréseket.
- Szerepkörönként távolról tartunk rövid egységeket, az Ön CMS-ének és szerverkörnyezetének példáival.
- Közösen kialakítjuk a jelentési utat, és kívánságra értékeljük a beérkező gyanújelentéseket.
- Egy biztonsági karbantartási szerződés keretében aktuális alkalmakkor megismételjük az egységeket, és rendszeresen ellenőrizzük a fiókokat.
Összegzés
A biztonságtudatosság a webes csapatban nem félelemből, hanem világosságból születik: mindenki ismeri a szerepkörét, a tipikus kockázatait és a szokatlan jelenségek jelentésének útját. A személyes fiókokkal és a kétfaktoros bejelentkezéssel kombinálva ez olyan védelem, amely a következő válsághéten is megállja a helyét.
Gyakori kérdések
Szükségük van a szerkesztőknek egyáltalán biztonsági képzésre?
Igen. A szerkesztők hozzáférnek a CMS-hez, fájlokat töltenek fel, és olyan leveleket kapnak, amelyek rendszerüzenetnek látszanak. Nem kell érteniük a technikához, de fel kell ismerniük, ha valami szokatlan, és tudniuk kell, kinek jelentsék.
Milyen gyakran kell képezni a webes csapatot?
Jobb röviden és rendszeresen, mint évente egyszer hosszan. Bevált a 15-20 perces egység néhány hetes időközökkel, kiegészítve egy alkalommal, például egy aktuális biztonsági helyzettel.
Mit tegyek, ha egy munkatárs rákattintott egy adathalász linkre?
Azonnal jelentesse, szemrehányás nélkül. Ezután meg kell változtatni az érintett jelszót, le kell zárni az aktív munkameneteket, és ellenőrizni kell, hogy módosítottak-e valamit a fiókkal. Minél korábban érkezik a jelentés, annál kisebb többnyire a kár.
Helyettesíti a képzés a technikai védelmi intézkedéseket?
Nem. A képzés és a technika kiegészítik egymást. A kétfaktoros bejelentkezés, a különálló szerepkörök és a naprakész szoftver felfogják azokat a hibákat is, amelyek jól képzett emberekkel is megtörténnek.