Kort sagt: Säkerhetsmedvetenhet hos medarbetare i webbteamet innebär: Varje person som sköter en webbplats känner till de tre–fyra riskerna för sin roll, känner igen avvikelser och rapporterar dem snabbt och utan rädsla för anklagelser. Redaktörer behöver annat innehåll än administratörer. Korta, återkommande enheter med exempel från det egna CMS:et verkar bättre än en obligatorisk utbildning en gång om året.
Varför webbteamet står i centrum just nu
Läget kring PHP2Shell har visat hur mycket som under några få dagar haglar över dem som driver webbplatser: varningar från BSI (tyska förbundskontoret för informationssäkerhet), meddelanden från hostingleverantörer, råd i forum och sociala nätverk, däribland felaktiga. I sådana veckor avgör inte bara administratörer utan också redaktörer, marknadsföring och assistenter vilket mejl de öppnar och vilken länk de klickar på.
Stora nyhetslägen är erfarenhetsmässigt ett tillfälle för bedragare. Räkna med mejl som utger sig för att vara hostingleverantören, CMS-tillverkaren eller ”IT-avdelningen” och uppmanar till en brådskande inloggning eller en påstådd säkerhetsuppdatering. Den som känner till det verkliga läget går sällan på det. Själva tekniska luckan stänger ingen redaktör, men en stulen administratörsåtkomst öppnar dörren även utan någon lucka.
Säkerhetsmedvetenhet för medarbetare: vem behöver vad?
En utbildning för alla med samma bilder missar oftast sitt mål. Mer rimligt är ett upplägg efter roller. Följande översikt hjälper vid planeringen:
| Roll | Typiska risker | Vad personen bör kunna |
|---|---|---|
| Redaktör, marknadsföring | nätfiskemejl, osäkra filuppladdningar, delade åtkomster | kontrollera avsändaren, bara ladda upp förväntade filtyper, aldrig lämna vidare egna inloggningsuppgifter |
| CMS-administratör | tillägg från okänd källa, för många administratörskonton, gamla konton efter tidigare medarbetare | dela ut rättigheter sparsamt, granska konton regelbundet, utökningar bara efter godkännande |
| Serveradministratör | ogranskade tips från nätet, ändringar utan logg, bortglömda testfiler | värdera källor, dokumentera ändringar, känna till nödvägen |
| Ledning | press att fatta snabba beslut, oklart ansvar | fastställa beslutsvägar, ta varningar på allvar, frigöra budget för förebyggande arbete |
| Extern byrå | gemensamma åtkomster, saknade överenskommelser | använda egna, personliga konton, aviser ändringar |
Tabellen visar också var tekniken måste hjälpa till. Personliga konton i stället för gemensamma åtkomster och tvåfaktorsinloggning för alla med skrivrättigheter tar mycket press från utbildningen. Hur det går till står under Tvåfaktorsinloggning för administratörsåtkomster.
Vad redaktörer behöver veta utan att bli tekniker
Redaktörer behöver inte veta vad en PHP-worker är. De bör däremot behärska tre saker säkert. För det första: En uppmaning att logga in på nytt ”på grund av en säkerhetsincident” hanteras aldrig via länken i mejlet, utan på det vanliga sättet in i CMS:et eller genom att fråga administratören.
För det andra: Rapportera avvikelser. Hit hör okända användarkonton i användarlistan, sidor eller inlägg som ingen har skapat, plötsliga omdirigeringar och varningar i webbläsaren. En redaktör ser ofta webbplatsen oftare än administratören och märker förändringar tidigare.
För det tredje: Hantera uppladdningar medvetet. Bilder och PDF-filer hör till vardagen, men en fil med ovanlig ändelse, ett arkiv ”för vidarebefordran” eller ett dokument med makron hör inte hemma i CMS:et. Om en fil inte går att ladda upp är det oftast avsikt och inget fel som man bör kringgå.
Vad administratörer behöver utöver detta
För administratörer handlar det mindre om nätfiske än om omdöme under tidspress. Under PHP2Shell-veckan cirkulerade råd som fackförfattare uttryckligen avvisar, till exempel att blockera alla förfrågningar med PHPSESSID. En översikt över sådana villospår ger inlägget Farliga felaktiga tips om PHP2Shell. Goda administratörer kontrollerar först primärkällan, alltså php.net, BSI eller tillverkaren, innan de ändrar en konfiguration.
Hit hör disciplin vid ändringar: Vad ändrades när och varför, och hur kan det tas tillbaka? En kort post i ärendet eller wikit räcker. I ett skarpt läge är den listan guld värd eftersom den visar vilken ändring som kommer från er och vilken inte.
Slutligen bör administratörer veta hur de känner igen ett möjligt intrång och vad man då inte ska göra: inte radera i panik, inte installera om direkt, utan säkra och rapportera. De typiska tecknen sammanfattar Är jag redan komprometterad?.
På 90 dagar till ett vaket webbteam
Ett program behöver inte vara stort för att verka. Dessa steg har visat sig fungera:
- Klargör beståndet (vecka 1 till 2): Vem har vilka åtkomster till CMS, hosting, domän och server? Lös upp gemensamma konton, spärra gamla konton.
- Fastställ rapporteringsväg (vecka 2): En adress eller en kanal för ”något verkar konstigt för mig”. Varje rapport besvaras, även om den var ofarlig.
- Första korta enheten per roll (vecka 3 till 4): 20 minuter, exempel från det egna CMS:et, skärmbilder av verkliga menyer.
- Införa tvåfaktorsinloggning (senast vecka 6): För alla med skrivrättigheter, med nödkoder på en säker plats.
- Övningsmejl och utvärdering (vecka 8): En förhandsannonserad testkampanj utan att enskilda personer blottställs. Utvärderingen gäller om det rapporterades, inte vem som klickade.
- Andra enheten kopplad till ett tillfälle (vecka 10 till 12): Till exempel en aktuell säkerhetssituation, genomspelad på det egna systemet.
Mät framgången i rapporter, inte i klickkvoter. Ett team som rapporterar mycket är vaket. Ett team som aldrig rapporterar är antingen perfekt eller osäkert, och det förstnämnda är sällsynt.
Hur hjälper PHP SOS konkret?
- Vi kartlägger tillsammans med er vem som har vilka åtkomster och visar gemensamma konton, överflödiga administratörer och bortglömda åtkomster.
- Vi håller korta enheter per roll på distans, med exempel från ert CMS och er servermiljö.
- Vi hjälper till att inrätta rapporteringsvägen och bedömer inkommande misstankar om ni önskar det.
- Inom ramen för ett säkerhetsunderhållsavtal upprepar vi enheterna vid aktuella tillfällen och granskar kontona regelbundet.
Slutsats
Säkerhetsmedvetenhet i webbteamet uppstår inte genom rädsla utan genom tydlighet: Alla känner till sin roll, sina typiska risker och vägen för att rapportera avvikelser. Tillsammans med personliga konton och tvåfaktorsinloggning är det ett skydd som håller även under nästa krisvecka.
Vanliga frågor
Behöver redaktörer över huvud taget en säkerhetsutbildning?
Ja. Redaktörer har åtkomst till CMS:et, laddar upp filer och får e-post som ser ut som systemmeddelanden. De behöver inte förstå tekniken, men ska känna igen när något är ovanligt och veta vem de ska rapportera det till.
Hur ofta bör webbteamet utbildas?
Hellre kort och regelbundet än en gång om året och långt. Enheter på 15 till 20 minuter med några veckors mellanrum har visat sig fungera, kompletterade med ett tillfälle kopplat till en aktuell säkerhetssituation.
Vad gör man om en medarbetare har klickat på en nätfiskelänk?
Låt rapportera direkt, utan anklagelser. Byt sedan det berörda lösenordet, avsluta aktiva sessioner och kontrollera om något har ändrats med kontot. Ju tidigare rapporten kommer, desto mindre blir skadan oftast.
Ersätter en utbildning tekniska skyddsåtgärder?
Nej. Utbildning och teknik kompletterar varandra. Tvåfaktorsinloggning, åtskilda roller och aktuell programvara fångar upp fel som även välutbildade människor gör.