Staatssecretaris ziet geen bezwaar tegen gebruik WordPress voor overheidssites

De staatssecretaris van Binnenlandse Zaken en Koninkrijksrelaties geeft aan dat hij geen bezwaar ziet tegen het gebruik van WordPress voor overheidswebsites, zoals die van de Informatiebeveiligingsdienst.

Demissionair staatssecretaris Raymond Knops vertelt dit naar aanleiding van Kamervragen van DENK-Kamerlid Van Baarle. Deze Kamervragen volgen een onderzoek van Trouw, dat claimde dat tientallen overheidswebsites op WordPress draaien en een openbaar toegankelijke inlogpagina voor admins hebben. Daardoor zouden ze eerder doelwit worden van kwaadwillenden, stelde Trouw in zijn artikel.

De websites voldoen hierom volgens Trouw niet aan richtlijnen die het Nationaal Cyber Security Centrum voorstelde voor overheidswebsites. Het NCSC adviseert onder andere om openbare pagina's en beheerderspagina's te scheiden. Dat gebeurt te weinig, stelde Trouw in juni.

Baseline Informatiebeveiliging Overheid

Knops haalde daarover op dinsdag de Baseline Informatiebeveiliging Overheid aan. Deze BIO is sinds 2019 van kracht en omvat een basisnormenkader voor de beveiliging van overheidsinstellingen. Dit kader stelt onder andere dat voorafgaand aan het gebruik van een informatiesysteem een risicoafweging moet worden gemaakt, die vervolgens richtinggevend is voor het nemen van beveiligingsmaatregelen, schrijft staatssecretaris Knops.

"Proportionaliteit is daarbij het uitgangspunt. Met andere woorden, gaat het om zeer vertrouwelijke informatie, dan worden andere afwegingen gemaakt dan wanneer het om openbare informatie gaat waarvan de beschikbaarheid belangrijk is."

Kader 9.4.2.1 van de BIO verplicht daarbij ook dat minimaal tweefactorauthenticatie verplicht is als 'vanuit een onvertrouwde zone toegang wordt verleend naar een vertrouwde zone'. Als dat niet kan, worden eisen gesteld aan de complexiteit van het wachtwoord. Ook moet toegang tot een account tijdelijk geblokkeerd worden na tien foutieve inlogpogingen en moeten wachtwoorden minstens ieder halfjaar worden veranderd.

Daarmee wordt het gebruik van WordPress en openbare inlogpagina's volgens Knops niet direct afgeraden, afhankelijk van de situatie en mits overheidsinstellingen de verplichte en benodigde beveiligingsmaatregelen treffen. De instanties zijn daarvoor zelf verantwoordelijk. "Het is aan overheidsorganisaties om, door het treffen van de verplichte maatregelen uit de BIO en aanvullende maatregelen, voortvloeiend uit een risicoafweging te bepalen hoe WordPress veilig kan worden ingezet."

Meldingen van WordPress-beveiligingsproblemen

Kamerlid Stephan van Baarle vraagt daarbij naar de veiligheidsrisico's van WordPress. Van Baarle stelt dat het Nationaal Cyber Security Centrum sinds 2014 gewaarschuwd heeft voor 36 beveiligingsproblemen in de software. Volgens Knops worden deze waarschuwingen 'nauwlettend in de gaten gehouden door afzonderlijke overheidsorganisaties'. "De BIO stelt eisen aan het toepassen van beveiligingspatches voor ernstige kwetsbaarheden in hard- en software."

Dergelijke meldingen van kwetsbaarheden zijn volgens Knops aan de orde van de dag en worden verstuuurd voor veel verschillende systemen. "Ik heb niet het beeld dat de hoeveelheid bekende kwetsbaarheden een exacte maatstaf is om de veiligheid van een product te beoordelen. Er spelen ook andere factoren mee, zoals de aard, omvang en frequentie van onderzoeken naar een product."

Van Baarle vraagt ook naar de mening van Knops over het feit dat de website van de Informatiebeveiligingsdienst op WordPress draait. Knops geeft daarbij aan dat deze website voldoet aan de eisen van de BIO. Ook zou de beheeromgeving van de IBD-website niet publiek zijn. Verder voert de IBD volgens Knops periodieke pentests uit om de beveiliging van zijn systemen te toetsen, waaronder de IBD-website valt. "Ik zie daarom geen bezwaar tegen het gebruik van individuele softwarepakketten, zoals WordPress, als risicoafwegingen zijn gemaakt en maatregelen zijn getroffen."

Reacties (94)

[Wekko]

De richtlijnen zijn ook niet helemaal ok om eerlijk te zijn. Door de login te verbergen maak je een applicatie of website niet per se veiliger. Security by obscurity is de grootste beginnersfout die developers kunnen maken. Verplicht ieder half jaar een nieuw wachtwoord wordt ook niet aangeraden in de huidige wetenschappelijke literatuur. Dit werkt onveilige wachtwoorden of onveilige opslag van wachtwoorden in de hand. Tegelijkertijd kan een uitgelekt wachtwoord nog maanden gebruikt worden.

[Stufipower]

Ik vind dat Knops een goed afgewogen standpunt heeft ingenomen.

2-FA is een aanzienlijke beveiliging. Bovendien zijn opensource softwarepakketten in mijn ogen waarschijnlijk veiliger dan maatwerk pakketten. En goedkoper natuurlijk.

Edit: eens met al jullie reacties. Beetje makkelijk misschien maar het zijn goede aanvullingen.

[Reactie gewijzigd door Stufipower op 22 juli 2024 22:55]

[CH4OS]

WordPress is vanuit de codebase bekeken echter ook oud. Dat betekend dat er mogelijk oude code is, wat heden ten dage gemakkelijker vatbaar is voor beveiligingslekken.

[GertMenkel]

Ik kijk voor mijn studie naar veiligheidslekken in WordPress. In de praktijk vind ik eigenlijk weinig grote lekken in WordPress zeker. De echte beuncode waardoor iedereen wordt gehackt zit hem in thema's, plugins en andere vage integraties van derden waarvan de codekwaliteit extreem ondermaats is.

Oude code is niet echt vatbaar voor veiligheidslekken, ononderhouden code is vatbaar voor veiligheidslekken. Hoe langer je code kan gebruiken zonder patches of updates, hoe stabieler en veiliger dat stuk code is. Dat heeft voor de onderhoudbaarheid natuurlijk flinke nadelen, maar de aanname dat oude code slechte code is, is echt onzin.

Windows bevat code uit NT 3.5 als je in de juiste module kijkt. Dat is niet de code waar de beveiligingslekken in worden gevonden.

[litebyte]

Het is opensource en denk wel een van de meest bekeken en gecontroleerde CMS'en dat er bestaat door beveiligingsexperts.

Als je in de inlog en protocollen hiervoor goed regelt en oplet met het gebruik van plugins van derden en een goed update beleid hebt. Kijk naar de meeste beveiligingsrisico's van Wordpress, en je komt meestal uit bij vaak opscure plugins of het gebruik van plugins die zogenaamd zijn genulled.

[CH4OS]

True, maar dat betekend niet dat het geen interessant pakket is voor hackers en beveiligingsonderzoekers om gaten te vinden in (met name) de oude code. Dat iets open source is en iedereen er aan mee kan sleutelen, betekend nog niet direct dat het pakket direct 'dus' maar veilig is, hoezeer ik open source ook een warm hart toedraag.

[Reactie gewijzigd door CH4OS op 22 juli 2024 22:55]

[Gubbel]

oude code !== onveilige code. Als iets veilig is, is het veilig. Iets wat 10 jaar geleden geschreven is, wordt niet ineens vandaag onveilig. Als er lekken in de oude code zaten, zijn die allang gedicht door de community. Het gaat bij WordPress vrijwel altijd om plugins of thema's en een onveilig configuratie.

De code van WordPress zelf is niets mis mee.

[AlkalineBug]

Ik ben wel met je eens dat oud niet per se onveilig betekent, maar niet met je eens dat iets wat 10 jaar geleden geschreven is niet "ineens" onveilig kan worden. Neem bijvoorbeeld het gebruik van hashing algoritmes als MD5 die 10 jaar geleden nog als veilig werden beschouwd, en ook nog veilig waren omdat kwetsbaarheden niet bekend waren, wordt MD5 nu als onveilig beschouwd. Daarnaast zijn er ook steeds meer aanvalsvectoren bekend waar in oude software geen rekening mee gehouden werd, ze waren niet bekend en werden dus ook niet benut.

En zelfs als de code zelf geen kwetsbaarheden bevat, is de kans enorm dat oude code afhankelijkheden bevat die zelf wel kwetsbaarheden bevatten. Het is zelden tot nooit zo dat voor een stuk code dat 10 jaar geleden is geschreven het wel mogelijk is alle dependencies te updaten. Als een stuk software groot genoeg is zal dit altijd kwetsbaarheden bevatten, en hoe meer tijd er overheen gaat hoe meer van deze kwetsbaarheden bekend zullen zijn, en dus bruikbaar voor aanvallen en daarom "onveiliger"

[Gubbel]

[quote]omdat kwetsbaarheden niet bekend waren[quote]
Mijn mening hierin is, dat het dus al kwetsbaar was, alleen niemand die het wist.
Mijn punt is meer dat de code zelf niet opeens onveilig wordt en dat bedoel ik letterlijk. Uiteraard kan de definitie van veilig veranderen en kan er geconcludeerd wordt dat oude code onveilig is, maar die code was dan altijd al onveilig alleen werd het niet zo beschouwd. Mierenneukerij, ik weet het, maar dat is wat ik bedoelde Verder ben ik het volledig met je eens.

[supersnathan94]

Iets wat 10 jaar geleden geschreven is, wordt niet ineens vandaag onveilig.

Jawel!. Want dingen die tien jaar geleden als veilig geacht werden kunnen dat vandaag niet meer zijn.

Dat is waarom zerodays nog steeds bestaan. Software is per definitie onveilig. Ook al voldoe je aan alle best practises. Het is wachten op een ZeroDay exploit ergens in je keten die de boel kompleet om zeep helpt.

De code van WordPress zelf is niets mis mee.

Nouuuuu jawel. Vorig jaar zijn er nog 21 kwetsbaarheden gevonden in de vorm van CVE's. Dat kan van alles zijn. DoS, SQLi, XSS. Dit jaar staat de teller op 3 .
https://www.cvedetails.co...press.html?vendor_id=2337

Een van de dit jaar gevonden issues is:

One of the blocks in the WordPress editor can be exploited in a way that exposes password-protected posts and pages.

Voor een overheidssite die daar misschien interne documenten achter heeft hangen geen issue om risico's mee te lopen.

[CH4OS]

Als oude code uitgaat van oude technieken en zaken aanroept die je eigenlijk niet meer wilt of kunt gebruiken, maar dat anno 2021 toch doet omdat anders de website het niet doet, dan is de kans op een lek groter dan wanneer de codebase gewoon up-to-date is en de website aangepast is naar modernere technieken. Code van 10 jaar geleden kan dus wel degelijk gevaarlijk zijn in dat op zicht, het geeft bij mij in elk geval aan dat de maintainers niet per se fan zijn van modernere technieken en workflows.

Ook daar kan een lek in zitten natuurlijk, maar meestal heb je dan wel dat die pakketten wel netjes maintained worden en makkelijker te onderhouden zijn (en daardoor ook langer supported is).

[litebyte]

Vrijwel elke populaire applicatie is interessant voor hackers - net zoals vrijwel elke drukke plek interessant is voor zakkenrollers. 35% van alle websites in de wereld draait Wordpress. Zoals je zelf al aangeeft, de code is oud, en hiermee bekend bij zowel hackers als beveiligingsexperts.

Als je kijkt waar de meeste WP 'hacks' uit bestaan dan zijn de meeste net als bij andere CMS/login portals van websites zogenaamde brute force attacks, op de 2de plek file exclusion attacks (al dan niet via plugins/scripts) en 3de SQL injections. Alle drie zijn relatief makkelijk tegen te gaan.

[mcDavid]

Verwar "oude" code niet met "niet onderhouden" code. Dat code oud is zegt weinig over de veiligheid. Als het al iets zegt is het waarschijnlijk positief, want hoe langer het mee gaat, hoe kleiner de kans dat er nog onontdekte kwetsbaarheden in zitten.
Als oude code niet meer onderhouden wordt, ontstaat er inderdaad een risico. Maar Wordpress wordt juist zéér actief onderhouden.

Ik wil mijn hand niet in het vuur steken voor een gemiddelde wordpress installatie, maar met de leeftijd van de codebase heeft dat weinig te maken.

[Ed Vertijsment]

Dat geld ook voor Windows, Linux, macOS Java en weet ik niet wat. Het gaat erom hoe er mee omgegaan wordt.

[litebyte]

Zeker. Ik zou me eerder druk maken over het gebruik van facebook/whatsapp door overheidsorg

[afterburn]

Daarnaast kun je ook prima het admin gedeelte van WP afschermen voor onbevoegden door bijvoorbeeld toegang te limiteren tot bepaalde (interne) IP adressen.

[Wh4ck0]

En als ze geen plugins gebruiken, nog beter, vaak zitten de lekken daar in. Wordpress security updates komen erg vaak, en kunnen zelfs automatisch worden uitgevoerd.

[wow7]

Kan dat alleen maar beamen , hier een mooi artikel van 14 juni 2021 van patchstack website.

[DJMaze]

Dat gaat niet makkelijk omdat een idioot heeft bedacht dat 'ajax' requests via wp-admin verlopen

[thomas1907]

Ik heb dit ooit gevonden op internet en dat werkt prima:

# Limit logins and admin by IP
AuthUserFile ../../.htpasswd
AuthName "Please Log In"
AuthType Basic
require valid-user
Order allow,deny
allow from x.x.x.x
satisfy any
<Files "admin-ajax.php">
Satisfy Any
Allow from all
</Files>

Of is dat weer onveilig omdat de ajax dan "open" staat?

[DJMaze]

Yep, natuurlijk zijn er dan weer lekken.
https://www.google.com/search?q=wordpress+exploit+ajax

[maevian]

Ajax heeft zeker wat gaten in zijn verdediging

[Jan-E]

Dan verplaats je de login-pagina met https://nl.wordpress.org/plugins/wps-hide-login/ en stelt die alleen maar open voor bepaalde IP adressen. Zelfs zonder IP blokkade is dat heel effectief tegen botjes die proberen in te loggen.

[Evil_king]

Mee eens. Ze hebben gewoon een impact analyse gedaan en daar is dit uitgekomen. Voelt haast een beetje van 'wij weten het beter dan hun hele IT afdeling', dat artikel dan. Ik bedoel: ja, de overheid is niet de beste wat betreft IT maar er werken daar ook gewoon intelligente mensen die een impact analyse en afweging kunnen maken......

[m_snel]

Je kan natuurlijk ook gewoon alles dicht zetten en niks op internet publiceren.
Je moet altijd een risico analyse doen ( impact analyse heeft alleen zin bij een aanpassing) .
En op basis daarvan beslis je of het acceptabel is.

[PolarBear]

Bovendien zijn opensource softwarepakketten in mijn ogen waarschijnlijk veiliger dan maatwerk pakketten.

Complexe pakketten zijn altijd lastig te onderhouden of het nu open- of closedsource is. De hoeveelheid programmeurs die complexe code goed kunnen reviewen is beperkt. Nu is het in de regel zo dat grote opensource projecten zoals Wordpress meestal wel een goede review hebben. Maar openssl heeft laten zien dat als het maar complex genoeg is mensen ook zaken missen. (en waar ik mensen zeg kan je ook geautomatiseerde tests invullen). En dan hebben we het nog niet over supplychain attacks.

Belangrijker is om niet uit te gaan van de aanname dat een pakket wel veilig zou zijn maar defense in depth in te voeren. Bijvoorbeeld in dit geval auditing zodat je weet dat er bestanden zijn aangepast bijvoorbeeld. Een WAF die specifiek de inlogpagina van Wordpress afschermt. Etc etc.

[Skit3000]

Uit de tekst blijkt ook dat de te nemen maatregelen zijn afhankelijk van het te lopen risico. Dat je geen gegevens van burgers op gaat slaan in een Wordpresssysteem lijkt mij wel duidelijk, maar als je het enkel gebruikt om enkele statische pagina's met overheidsinformatie te tonen dan is het risico hooguit dat je website na een hack offline is tot een backup teruggeplaatst kan worden. Blijkt dus uit een risico-inventarisatie dat het prima is dat een website een x-aantal uur offline is en er enkel publieke data op getoond wordt, dan lijkt Wordpress mij een prima keus mits je dan wel zaken inricht zoals backup- en restoreprocessen én audits uitvoert dat de gegevens op de pagina niet door derden zijn aangepast (door bijvoorbeeld geautomatiseerd regelmatig een kopie te vergelijken met wat op dat moment in productie is).

[peize9]

Opzich goed advies. Het gebruik van wordpress is verder geen probleem. Wel is het belangrijk dat ze de site regelmatig updaten, dat is waardoor het het vaakste mis gaat.

[Noxious]

WordPress installeert al heel lang automatisch security updates, dat risico is sinds die toevoeging al heel veel kleiner.

[delphium]

En dat doet Wordpress alleen asl je de webserver volledige schrijfrechten geeft op de code van je website, wat dan weer een veiligheidsrisico op zichzelf is.

[Elidibus]

Inderdaad, plus moet er ook gekeken worden naar wat voor soort website het is en wat de gebruiker er op doet. Als het puur informatief is, kan het nog wel schadelijk zijn als die gehackt wordt, maar is de impact vaak minder dan bij een overheidssite die een DigiD implementatie heeft.

[darkdeathrip]

"Hierbij bied ik u de antwoorden aan op de schriftelijke vragen die zijn gesteld
door het lid Van Baarle (DENK) over de huidige stand van zaken met betrekking
tot de digitale beveiliging van overheidswebsites in Nederland."

Wel grappig dat niemand het heeft over de website van DENK zelf, die is namelijk in Wordpress.
Een gevalletje "Wij van WC eend...".

[Reactie gewijzigd door darkdeathrip op 22 juli 2024 22:55]

[OxWax]

Ja maar DENK is een kleine partij, de Overheid daarentegen ...

[darkdeathrip]

Zelfs daar gaat het mis, mocht je weten waar je moet zoeken de wp-json users staan gewoon naar buiten open.

[Tomatoman]

De Kamervragen van DENK lijken ook vooral te zijn ingegeven door een kans om gemakkelijk wat media-aandacht te kunnen scoren in komkommertijd. Sommige vragen aan de minister zijn behoorlijk suggestief gesteld:

Vraag 3
Erkent u dat de overheid tekort heeft geschoten in het treffen van digitale beveiligingsmaatregelen tegen eventuele hackers?

Vraag 4
Deelt u de mening dat de burgers erop zouden moeten kunnen vertrouwen dat overheden als de Belastingdienst, GGD's, veiligheidsregio's en waterschappen, vertrouwelijk en verantwoord met gevoelige gegevens omspringen? Zo nee, waarom niet?

[sjettepetJR.]

vraag 3 vind ik persoonlijk nog wel kunnen. de discussie of een beveiligingslek een ongeluk is of dat het daadwerkelijk een gevolg is van nalatigheid is vaak nog wel interessant. ook als je alles volgens het boekje doet kan er nog wel eens beveiligingslek zijn.

vraag 4 daarentegen slaat helemaal nergens op natuurlijk.

[Stroopwafels]

Van Baarle stelt dat het Nationaal Cyber Security Centrum sinds 2014 gewaarschuwd heeft voor 36 beveiligingsproblemen in de software.

Een groter probleem betreft WordPress zijn de duizenden plugins die kunnen worden geïnstalleerd. Vaak zijn erg veel van deze plugins kwetsbaar voor dingen zoals CSRF, SQL injection, privilege escalation en XSS. Dit komt erg vaak voor, zelfs in plugins die miljoenen installaties hebben.

Hier even 3 voorbeelden:
https://www.techradar.com...or-to-millions-of-attacks
https://www.searchenginej...gin-vulnerability/406921/
https://blog.sucuri.net/2...in-infinitewp-client.html

Hier 2 sites die een database bijhouden van kwetsbaarheden in WordPress plugins.
https://patchstack.com/database/
https://wpscan.com/plugins

[Reactie gewijzigd door Stroopwafels op 22 juli 2024 22:55]

[geert1]

De risico's van plugins en thema's zijn inderdaad groter dan die van Wordpress core. De hoofdapplicatie wordt behoorlijk doorgelicht en zwakheden daarin worden snel bekend, en snel opgelost. Op dit vlak zijn er weinig tot geen grote rampen geweest.

Maar ook de plugins en thema's zijn geen rampzalige situatie. De databases die je linkt laten zien dat problemen veruit het vaakst voorkomen bij kleinere, onbekende plugins/thema's, en dan nog vaak maar voor korte tijd. Elke Wordpress-ontwikkelaar die z'n snot waard is zoekt sowieso al naar de meest betrouwbare, meest breed gedragen oplossingen en komt dus zelden met de prutsers in aanraking.

Een serieus probleem in een populaire plugin zoals Yoast, Elementor of WooCommerce wordt nóg flink sneller aangepakt, en die partijen hebben veelal ook pro-actieve beveiligingsverbeteringen.

Dus: Wordpress is minstens zo veilig als soortgelijke pakketten (closed en open source), mits de plugins en thema's goed gekozen zijn, er vaak wordt bijgewerkt, en de verdere beveiliging op orde wordt gebracht naar gelang de risico's. Dat laatste is bijvoorbeeld 2FA, afscherming van het beheerpaneel en verstandig beleid wat betreft gebruikers, rechten en wachtwoorden. Wat net zo goed verstandig is voor alle andere pakketten, en dan vooral voor overheid, zorg en andere sites met hoger risico.

[Christoxz]

WordPress draaien en daarmee een openbaar toegankelijke inlogpagina voor admins hebben.

Het NCSC adviseert onder andere om openbare pagina's en beheerderspagina's te scheiden.

Prima advies en lijkt mij ook verstandig. WP is natuurlijk populair en krijgt daardoor ook veel aandacht van hackers, maar natuurlijk ook beveiligingonderzoekers.

https://www.cvedetails.co...press.html?vendor_id=2337

[CH4OS]

Het gaat daarnaast (en zoals jouw linkje ook laat zien) ook de nodige jaren al mee. Niet alles zal daardoor een keer gemoderniseerd zijn, waardoor lekken/gaten in oude code niet eens ondenkbaar zijn en de kans dat juist daar een fout gevonden wordt, vrij groot is.

[Chris_147]

En net daardoor heeft het ook al een zekere maturiteit die een nieuw(er) pakket niet heeft.
Als je netjes update, plugins beperkt en toegang afschermt kan er op zich weinig gebeuren.

[RoseSW]

Zie verschillende comments van je betreft "oude code"

WordPress wordt bewust backwards compatible gehouden.

Als je echt veel zorgen maakt om een stuk code kun je een issue openen en je pleidooi houden, als men vindt dat je een goed punt hebt, dan kan het worden veranderd.

Het is en blijft een open source community, met een sterke commerciele kant, met soms stevige discussies, en aanpassingen op maat. Neem Gutenberg bijvoorbeeld, op verzoek van de community kun je dat gewoon uitzetten.

Veel dingen kun je ook uitzetten of maatregelen tegen nemen bijvoorbeeld.

Welke oude code maak je bijvoorbeeld zorgen om?

WordPress is niet perfect, maar dingen zoals het Trouw artikel lieten steken vallen, en reacties zoals het bevat "oude code" zie ik zelf liever wat concreter, zodat er naar gekeken kan worden of iets een issue is, en niet zomaar wat gebrul

[CH4OS]

Zie verschillende comments van je betreft "oude code"

WordPress wordt bewust backwards compatible gehouden.

Als je echt veel zorgen maakt om een stuk code kun je een issue openen en je pleidooi houden, als men vindt dat je een goed punt hebt, dan kan het worden veranderd.

Het is en blijft een open source community, met een sterke commerciele kant, met soms stevige discussies, en aanpassingen op maat. Neem Gutenberg bijvoorbeeld, op verzoek van de community kun je dat gewoon uitzetten.

Veel dingen kun je ook uitzetten of maatregelen tegen nemen bijvoorbeeld.

Welke oude code maak je bijvoorbeeld zorgen om?

WordPress is niet perfect, maar dingen zoals het Trouw artikel lieten steken vallen, en reacties zoals het bevat "oude code" zie ik zelf liever wat concreter, zodat er naar gekeken kan worden of iets een issue is, en niet zomaar wat gebrul

Het ging mij in deze meer over het algemeen, waarbij ik WordPress min of meer als voorbeeld heb gebruikt. Ik ben niet meer zo into WordPress, ik gebruik het alleen nog om een hele enkele keer een kleine, simpele website neer te zetten, waarbij iemand anders met een WYSIWYG editor aan de slag kan om pagina's te schrijven. Dat gebeurd echter nauwelijks nog, dus gebruik het ook nauwelijks meer. Ik kan dus een algemeen pleidooi gaan houden, maar denk niet dat men daar tijd in gaat steken.

[Jonathan-458]

Wordpress is een van de populairste CMS/Website builders, zoals @Christoxz al aangeeft krijgt wordpress hierdoor extra aandacht van zoal wel hackers als researchers en is het gewoon belangrijk om dit continue up-to-date te houden.

De grotere uitdaging zit bij de veiligheid van de diverse plugins.

M.b.t. publieke inlog, gewoon de standaard login URL aanpassen naar een uniek adres, beperken tot welke ip's toegang hebben & 2FA instellen.

[Videopac]

Het gaat er natuurlijk om dat je als overheid de vereisten voor overheidsites vastlegd. En als Wordpress daar dan aan voldoet: prima.

Dus niet focussen op het pakket / de tool maar op de minimale eisen. Een tool die vandaag goed is kan morgen problematisch zijn. Focus op het doel (veilige, beheerbare omgevingen), niet op de middelen (tool x/y/z).

[Arboris]

Ik maak me niet zo zeer zorgen om de Wordpress basis installatie, maar wel om de (vaak onveilige) plugins die men gebruikt...

[CAPSLOCK2000]

Ik vind de antwoorden van Knops best goed, zeker voor iemand die helemaal moet vertrouwen op experts.

In praktijk worstel ik erg met proportionaliteit. Het klinkt namelijk als een meer dan goed idee om je beveilingsmaatregelen aan te passen aan wat er beveiligd wordt. Dat je een simpele informatie-site anders beveiligd dan een site met medische gegevens.

Maar in praktijk zie ik dat soort denken niet bij de gebruiker en enorm veel feature creep.
Die twee samen komen er op neer dat gebruikers ieder goedgekeurd systeem zullen gebruiken voor alle soorten data. Zo heb ik hier verschillende vormen van "netwerkopslag" (lokaal, in de cloud, windows shares, met/zonder backup, met/zonder encryptie) die ook allemaal hun eigen beveiligingsklassificatie hebben. Maar geen gebruiker kan uitleggen wanneer je nu de ene of de andere vorm van storage moeten gebruiken en welke regels daar bij horen. Die kijken vooral naar zaken als "waar heb ik ruimte, waar mag mijn collega bij, waar kan ik vanaf thuis bij".

Zelfs als een systeem in eerste instantie netjes en schoon is opgezet dan blijft dat niet zo als je daar niet hard aan werkt. Als er eenmaal ergens "iets" staat, dan gaan mensen vanzelf dingen die er bij "passen" opslaan op hetzelfde platform, want dat is handig. Je moet maar hopen dat de volgende een goed besef heeft van de regels en ze kan toepassen. Want per ongeluk data laten lekken is net zo erg als het opzettelijk doen.

De situatie lijkt erg op hoe we 10 jaar geleden met HTTPS omgingen en alleen "belangrijke" sites beveiligde. Tot we er achter kwamen dat er geen harde lijn te trekken is tussen "belangrijke" en "onbelangrijke" sites, dat die classificatie nog wel eens verandert en dat mensen nou eenmaal fouten maken. Toen hebben we uiteindelijk de conclusie getrokken dat het minder moeite is om maar overal https te gebruiken dan om per geval een beslissing te nemen die je steeds opnieuw moet evalueren.

PS. Dit heeft alles heeft niks met Wordpress te maken. Ik probeer niet te zeggen dat we overal wel/geen WP moeten gebruiken. Mijn boodschap is dat 'proportionaliteit' een lastig begrip is omdat er meestal aannames worden gedaan die in praktijk niet hard gemaakt kunnen worden.