Kort gezegd: Security awareness voor medewerkers in het webteam betekent: iedereen die een website onderhoudt, kent de drie tot vier risico's van de eigen rol, herkent afwijkingen en meldt ze snel en zonder angst voor verwijten. Redacteuren hebben andere inhoud nodig dan beheerders. Korte, terugkerende eenheden met voorbeelden uit het eigen CMS werken beter dan een jaarlijkse verplichte training.
Waarom juist nu het webteam centraal staat
De situatie rond PHP2Shell heeft laten zien hoeveel er binnen enkele dagen op beheerders van websites afkomt: waarschuwingen van het BSI (Duitse federale dienst voor informatiebeveiliging), meldingen van hosters, adviezen op forums en sociale netwerken, waaronder ook onjuiste. In zulke weken beslissen niet alleen beheerders, maar ook redacteuren, marketing en assistenten welke mail ze openen en op welke link ze klikken.
Grote nieuwsgebeurtenissen zijn volgens ervaring een aanleiding voor oplichters. Reken op mails die zich voordoen als hoster, CMS-fabrikant of „IT-afdeling“ en oproepen tot een dringende aanmelding of een zogenaamde beveiligingsupdate. Wie de echte situatie kent, trapt er minder snel in. Het technische lek zelf dicht geen enkele redacteur, maar een gestolen beheerderstoegang opent de deur ook zonder lek.
Security awareness voor medewerkers: wie heeft wat nodig?
Een training voor iedereen met dezelfde sheets mist meestal haar doel. Zinvoller is maatwerk per rol. Het volgende overzicht helpt bij de planning:
| Rol | Typische risico's | Wat de persoon moet kunnen |
|---|---|---|
| Redacteur, marketing | phishingmails, onveilige bestandsuploads, gedeelde toegangen | afzender controleren, alleen verwachte bestandstypen uploaden, eigen inloggegevens nooit doorgeven |
| CMS-beheerder | plug-ins uit onbekende bron, te veel beheerdersaccounts, oude accounts van vertrokken medewerkers | rechten spaarzaam toekennen, accounts regelmatig controleren, uitbreidingen alleen na goedkeuring |
| Serverbeheerder | ongecontroleerde tips van het internet, wijzigingen zonder logboek, vergeten testbestanden | bronnen beoordelen, wijzigingen documenteren, noodroute kennen |
| Directie | druk op snelle beslissingen, onduidelijke verantwoordelijkheden | beslissingsroutes vastleggen, meldingen serieus nemen, budget voor preventie vrijgeven |
| Extern bureau | gemeenschappelijke toegangen, ontbrekende afspraken | eigen, persoonlijke accounts gebruiken, wijzigingen aankondigen |
De tabel toont ook waar techniek moet helpen. Persoonlijke accounts in plaats van verzamelaccounts en tweefactorauthenticatie voor iedereen met schrijfrechten nemen veel druk van de training weg. Hoe dat werkt, leest u onder Tweefactorauthenticatie voor beheerderstoegangen.
Wat redacteuren moeten weten zonder technicus te worden
Redacteuren hoeven niet te weten wat een PHP-worker is. Drie dingen moeten ze echter zeker beheersen. Ten eerste: een oproep om „vanwege een beveiligingsincident“ opnieuw in te loggen, wordt nooit afgehandeld via de link in de mail, maar via de gebruikelijke weg naar het CMS of met een vraag aan de beheerder.
Ten tweede: afwijkingen melden. Daartoe behoren onbekende gebruikersaccounts in de gebruikerslijst, pagina's of berichten die niemand heeft aangemaakt, plotselinge doorverwijzingen en waarschuwingen in de browser. Een redacteur ziet de website vaak vaker dan de beheerder en merkt veranderingen eerder op.
Ten derde: uploads bewust behandelen. Afbeeldingen en pdf's zijn dagelijkse kost, maar een bestand met een ongebruikelijke extensie, een archief „ter doorsturing“ of een document met macro's hoort niet in het CMS. Als een bestand niet kan worden geüpload, is dat meestal opzet en geen fout die u moet omzeilen.
Wat beheerders er extra bij nodig hebben
Voor beheerders gaat het minder om phishing dan om oordeelsvermogen onder tijdsdruk. In de PHP2Shell-week circuleerden adviezen die vakauteurs uitdrukkelijk afwijzen, bijvoorbeeld alle verzoeken met PHPSESSID blokkeren. Een overzicht van zulke dwaalsporen biedt het artikel Gevaarlijke valse tips over PHP2Shell. Goede beheerders raadplegen eerst de primaire bron, dus php.net, het BSI of de fabrikant, voordat ze een configuratie wijzigen.
Daarbij hoort discipline bij wijzigingen: wat is wanneer waarom gewijzigd, en hoe is het terug te draaien? Een korte vermelding in het ticket of de wiki volstaat. In een noodgeval is deze lijst goud waard, omdat ze laat zien welke wijziging van u komt en welke niet.
Ten slotte moeten beheerders weten waaraan ze een mogelijke inbraak herkennen en wat ze dan niet moeten doen: niet haastig verwijderen, niet direct opnieuw installeren, maar veiligstellen en melden. De typische signalen vat Ben ik al gecompromitteerd? samen.
In 90 dagen naar een alert webteam
Een programma hoeft niet groot te zijn om te werken. Deze stappen hebben zich bewezen:
- Bestand opnemen (week 1 tot 2): wie heeft welke toegangen tot CMS, hosting, domein en server? Verzamelaccounts opheffen, oude accounts blokkeren.
- Meldroute vastleggen (week 2): een adres of kanaal voor „er komt me iets vreemd voor“. Elke melding wordt beantwoord, ook als ze onschuldig bleek.
- Eerste korte eenheid per rol (week 3 tot 4): 20 minuten, voorbeelden uit het eigen CMS, schermafbeeldingen van echte menu's.
- Tweefactorauthenticatie invoeren (tot week 6): voor iedereen met schrijfrechten, met noodcodes op een veilige plek.
- Oefenmail en evaluatie (week 8): een aangekondigde testcampagne zonder individuen te kijk te zetten. Geëvalueerd wordt of er is gemeld, niet wie heeft geklikt.
- Tweede eenheid bij een aanleiding (week 10 tot 12): bijvoorbeeld een actuele beveiligingssituatie, doorgespeeld op het eigen systeem.
Meet het succes aan meldingen, niet aan klikpercentages. Een team dat veel meldt, is alert. Een team dat nooit meldt, is ofwel perfect ofwel onzeker, en het eerste komt zelden voor.
Hoe helpt PHP SOS concreet?
- Wij leggen samen met u vast wie welke toegangen heeft en laten verzamelaccounts, overtollige beheerders en vergeten toegangen zien.
- Wij houden korte eenheden per rol op afstand, met voorbeelden uit uw CMS en uw serveromgeving.
- Wij richten de meldroute mee in en beoordelen binnenkomende vermoedensmeldingen als u dat wenst.
- In het kader van een beveiligingsonderhoudscontract herhalen wij de eenheden bij actuele aanleidingen en controleren wij de accounts regelmatig.
Conclusie
Veiligheidsbewustzijn in het webteam ontstaat niet door angst, maar door duidelijkheid: iedereen kent zijn rol, zijn typische risico's en de weg om afwijkingen te melden. In combinatie met persoonlijke accounts en tweefactorauthenticatie is dat een bescherming die ook de volgende crisisweek overeind blijft.
Veelgestelde vragen
Hebben redacteuren eigenlijk een beveiligingstraining nodig?
Ja. Redacteuren hebben toegang tot het CMS, uploaden bestanden en ontvangen mails die op systeemberichten lijken. Ze hoeven de techniek niet te begrijpen, maar moeten herkennen wanneer iets ongebruikelijk is en weten aan wie ze het melden.
Hoe vaak moet het webteam worden getraind?
Beter kort en regelmatig dan eens per jaar lang. Beproefd zijn eenheden van 15 tot 20 minuten met enkele weken ertussen, aangevuld met een aanleiding zoals een actuele beveiligingssituatie.
Wat te doen als een medewerker op een phishinglink heeft geklikt?
Laat het direct melden, zonder verwijt. Wijzig dan het betreffende wachtwoord, beëindig actieve sessies en controleer of met het account iets is veranderd. Hoe eerder de melding komt, hoe kleiner de schade meestal is.
Vervangt een training technische beschermingsmaatregelen?
Nee. Training en techniek vullen elkaar aan. Tweefactorauthenticatie, gescheiden rollen en actuele software vangen fouten op die ook goed getrainde mensen overkomen.