Kort sagt: Security awareness for medarbejdere i webteamet betyder: Hver person, der vedligeholder et website, kender de tre til fire risici ved sin rolle, genkender påfaldende forhold og melder dem hurtigt og uden frygt for bebrejdelser. Redaktører har brug for andet indhold end administratorer. Korte, tilbagevendende enheder med eksempler fra eget CMS virker bedre end en årlig obligatorisk uddannelse.
Hvorfor netop webteamet er i centrum nu
Situationen omkring PHP2Shell har vist, hvor meget der på få dage regner ned over websiteejere: advarsler fra BSI (det tyske forbundsagentur for informationssikkerhed), meddelelser fra hostingudbydere, råd i fora og sociale netværk, herunder også forkerte. I sådanne uger afgør ikke kun administratorer, men også redaktører, marketing og assistance, hvilken mail de åbner, og hvilket link de klikker på.
Store nyhedssituationer er erfaringsmæssigt en anledning for svindlere. Regn med mails, der udgiver sig for at være hostingudbyderen, CMS-producenten eller "it-afdelingen" og opfordrer til et hastende login eller en angivelig sikkerhedsopdatering. Den, der kender den rigtige situation, falder sjældnere for det. Selve den tekniske sårbarhed lukker ingen redaktør, men en stjålet admin-adgang åbner døren også uden sårbarhed.
Security awareness for medarbejdere: Hvem har brug for hvad?
En uddannelse for alle med de samme slides rammer som regel ved siden af. Mere fornuftigt er en tilpasning efter roller. Det følgende overblik hjælper ved planlægningen:
| Rolle | Typiske risici | Hvad personen bør kunne |
|---|---|---|
| Redaktør, marketing | phishingmails, usikre filuploads, delte adgange | kontrollere afsenderen, kun uploade forventede filtyper, aldrig give egne loginoplysninger videre |
| CMS-administrator | plugins fra ukendt kilde, for mange admin-konti, gamle konti fra tidligere medarbejdere | tildele rettigheder sparsomt, kontrollere konti regelmæssigt, udvidelser kun efter godkendelse |
| Serveradministrator | ukontrollerede tips fra nettet, ændringer uden protokol, glemte testfiler | vurdere kilder, dokumentere ændringer, kende nødvejen |
| Direktion | pres for hurtige beslutninger, uklart ansvar | fastlægge beslutningsveje, tage meldinger alvorligt, frigive budget til forebyggelse |
| Eksternt bureau | fælles adgange, manglende aftaler | bruge egne, personlige konti, varsle ændringer |
Tabellen viser også, hvor teknikken må hjælpe. Personlige konti i stedet for fælles adgange og et totrinslogin for alle med skriveret tager meget pres af uddannelsen. Hvordan det gøres, står under Totrinslogin til admin-adgange.
Hvad redaktører skal vide uden at blive teknikere
Redaktører behøver ikke vide, hvad en PHP-worker er. De bør dog beherske tre ting sikkert. For det første: En opfordring til at logge ind igen "på grund af en sikkerhedshændelse" klares aldrig via linket i mailen, men ad den vante vej ind i CMS'et eller ved at spørge administratoren.
For det andet: Melde påfaldende forhold. Hertil hører ukendte brugerkonti i brugerlisten, sider eller indlæg, som ingen har oprettet, pludselige omdirigeringer og advarsler i browseren. En redaktør ser ofte websitet hyppigere end administratoren og lægger tidligere mærke til ændringer.
For det tredje: Håndtere uploads bevidst. Billeder og PDF'er er hverdag, men en fil med en ualmindelig endelse, et arkiv "til videresendelse" eller et dokument med makroer hører ikke hjemme i CMS'et. Hvis en fil ikke kan uploades, er det som regel med vilje og ikke en fejl, man bør omgå.
Hvad administratorer har brug for derudover
For administratorer handler det mindre om phishing end om dømmekraft under tidspres. I PHP2Shell-ugen kursede der råd, som fagforfattere udtrykkeligt afviser, f.eks. at blokere alle forespørgsler med PHPSESSID. Et overblik over sådanne vildspor giver indlægget Farlige falske tips om PHP2Shell. Gode administratorer kontrollerer først primærkilden, altså php.net, BSI eller producenten, før de ændrer en konfiguration.
Hertil hører disciplin ved ændringer: Hvad blev ændret hvornår og hvorfor, og hvordan kan det tages tilbage? En kort post i ticket eller wiki er nok. I en nødsituation er denne liste guld værd, fordi den viser, hvilken ændring der stammer fra jer, og hvilken der ikke gør.
Endelig bør administratorer vide, hvordan de genkender et muligt indbrud, og hvad der så ikke skal gøres: ikke slette i hast, ikke straks geninstallere, men sikre og melde. De typiske tegn opsummerer Er jeg allerede kompromitteret?.
Et vågent webteam på 90 dage
Et program behøver ikke være stort for at virke. Disse skridt har vist sig at fungere:
- Afklar beholdningen (uge 1 til 2): Hvem har hvilke adgange til CMS, hosting, domæne og server? Opløs fælleskonti, spær gamle konti.
- Fastlæg meldevejen (uge 2): En adresse eller en kanal til "noget ser mærkeligt ud for mig". Hver melding besvares, også hvis den var harmløs.
- Første korte enhed pr. rolle (uge 3 til 4): 20 minutter, eksempler fra eget CMS, skærmbilleder af ægte menuer.
- Indfør totrinslogin (inden uge 6): For alle med skriveret, med nødkoder opbevaret på et sikkert sted.
- Øvelsesmail og evaluering (uge 8): En varslet testkampagne uden at udstille enkeltpersoner. Der evalueres, om der blev meldt, ikke hvem der klikkede.
- Anden enhed ud fra en anledning (uge 10 til 12): For eksempel en aktuel sikkerhedssituation, gennemspillet på eget system.
Mål succes på meldinger, ikke på klikrater. Et team, der melder meget, er vågent. Et team, der aldrig melder, er enten perfekt eller usikkert, og det første er sjældent.
Hvordan hjælper PHP SOS konkret?
- Vi kortlægger sammen med jer, hvem der har hvilke adgange, og viser fælleskonti, overtallige administratorer og glemte adgange.
- Vi holder korte enheder pr. rolle på afstand, med eksempler fra jeres CMS og jeres servermiljø.
- Vi er med til at opsætte meldevejen og vurderer indkomne mistankemeldinger, hvis I ønsker det.
- Inden for rammerne af en sikkerhedsvedligeholdelsesaftale gentager vi enhederne ved aktuelle anledninger og kontrollerer kontiene regelmæssigt.
Konklusion
Sikkerhedsbevidsthed i webteamet opstår ikke af frygt, men af klarhed: Alle kender deres rolle, deres typiske risici og vejen til at melde påfaldende forhold. Kombineret med personlige konti og totrinslogin er det en beskyttelse, der også holder i den næste kriseuge.
Ofte stillede spørgsmål
Har redaktører overhovedet brug for sikkerhedsuddannelse?
Ja. Redaktører har adgang til CMS'et, uploader filer og modtager mails, der ligner systembeskeder. De behøver ikke forstå teknikken, men skal genkende, når noget er usædvanligt, og vide, hvem de skal melde det til.
Hvor ofte bør webteamet skoleres?
Hellere kort og regelmæssigt end én gang om året i lang tid. Enheder på 15 til 20 minutter med få ugers mellemrum har vist sig at fungere, suppleret med en anledning som en aktuel sikkerhedssituation.
Hvad gør man, hvis en medarbejder har klikket på et phishinglink?
Lad medarbejderen melde det med det samme, uden bebrejdelser. Skift derefter den berørte adgangskode, afslut aktive sessioner, og kontrollér, om der er ændret noget med kontoen. Jo tidligere meldingen kommer, desto mindre er skaden som regel.
Erstatter en uddannelse tekniske beskyttelsesforanstaltninger?
Nej. Uddannelse og teknik supplerer hinanden. Totrinslogin, adskilte roller og aktuel software opfanger fejl, som også sker for veluddannede mennesker.