Directeur Peter Stoffelen spreekt van een wake-upcall om in het vervolg beter naar de beveiliging te kijken.
"Dit lek is veroorzaakt door een contactformulier dat we nog niet zo lang geleden aan onze website hebben toegevoegd. Met dat formulier zijn zo’n 400 documenten geüpload."
Ik ben bang dat het voorlopig niet goed gaat komen. Deze twee zinnetjes vertellen mij dat ze eigenlijk nog niet beseffen wat er mis is gegaan. Populair gezegd: er is een auto tegen een muur aangereden en ze hebben het over de deuken in de bumper maar vragen zich niet af waarom er geen remmen in de auto zaten en waarom de chauffeur niet heeft bijgestuurd.
Natuurlijk was het beter geweest als er geen fout in dat contacformulier had gezeten, maar zonder verschillende onderliggende problemen was het niet op deze manier fout gegaan. Ik kan me niet voorstellen dat dit het eerste formulier op die site is. Als andere formulieren dit probleem niet hebben dan wijst het er op dat er (in dit geval) geen gebruik is gemaakt van een standaard framework of library. Normaal gesproken zou je namelijk verwachten dat dit soort problemen worden opgevangen door zo'n framework, dat is namelijk een belangrijke reden om daar gebruik van te maken.
Het lijkt mij dus waarschijnlijk dat hier iemand is afgeweken van de standaard of dat er uberhaupt geen standaard is. Nu worden natuurlijk over fouten gemaakt, maar je zou een proces moeten hebben om fouten te voorkomen. Een handmatig gebouwd formuliertje zou daar onmiddelijk moeten zijn tegengehouden.
Een vergelijkbaar verhaal kun je houden over de URLs met voorspelbare/aanpasbare nummers er in, dat zou ook bij de controle moeten zijn tegengehouden.
We hebben dus al iemand die niet het juiste gereedschap inzet en geen proces om dat te voorkomen.
Dan een aanname die ik baseer op veel ervaring: waarschijnlijk werden de bestanden die de gebruikers uploadden weggeschreven in een directory die de webserver rechstreeks kan uitlezen terwijl dat eigenlijk niet de bedoeling is. In een professionele omgeving hoor je de verschillende applicaties die een website verzorgen (webserver, database, php-of-een-andere-taal) strict te scheiden, net als de bestanden die de verschillende onderdelen nodig zijn. Je wil bijvoorbeeld niet dat je webserver de configuratie van de database kan overschrijven. Een van de basisregels die daar uit voorkomt is dat als gebruikers bestanden uploaden dat je die in een aparte directory zet waar de rest van het systeem niet zomaar bij kan. In praktijk zie ik dat vaak fout gaat omdat het coordinatie vereist tussen de systeembeheerder en de applicatiebeheerder en/of ontwikkelaar. Zeker in de markt voor budgethosting bestaat die niet en is het de gewoonte om alle bestanden maar op een grote hoop te vegen. Veel ontwikkelaars lijken niet beter te weten.
Ik zal maar niet beginnen over moderne ideeen zoals dat je alle data en bestanden standaard versleuteld zodra ze binnen komen zodat als bestanden uitlekken dat niet veel kwaad kan.
De manier waarom directeur Peter Stoffelen spreekt over "een wake-upcall om in het vervolg beter naar de beveiliging te kijken" geeft een beetje hoop, maar het is maar de vraag of hij beseft dat het hier niet gaat om een klein incident dat je achteraf kan rechtzetten, maar dat het wijst op een fundamenteel proces waardoor er waarschijnlijk veel meer fouten zijn die nog niet aan het licht zijn gekomen.
Iedere organisatie in de wereld is tegenwoordig een IT-organisatie maar de meesten beseffen dat niet. Dat gaat heel erg fout zodra ze dingen buiten de deur willen plaatsen of aanbesteden. Ze snappen namelijk niet dat je wel techniek en diensten kan kopen maar dat dit slechts middelen zijn. Je hebt nog steeds "echte" IT-ers nodig om alles aan elkaar te knopen. De meeste problemen in de IT komen ontstaan op het koppelvlak tussen applicaties en doordat verschillende onderdelen verschillende aannames doen. Daarvoor is namelijk kennis en inzicht nodig van de organisatie waar je voor werkt. Dat kun je niet inkopen.
Het is alsof een bedrijf 100 typemachines en een woordenboek koopt en denkt dat ze dan literaire romans kunnen laten schrijven door de onderhoudsmonteur.
Ik wil nog even benadrukkken dat ik niet weet wat er echt aan de hand is. Het kan natuurlijk dat ze echt enorm veel pech hebben gehad met een samenloop van omstandigheden en dat het eigenlijk allemaal prima geregeld is. Maar gezien er al eerder zo'n incident is geweest geef ik ze hier niet het voordeel van de twijfel.
Die vorige fout is op zich wel interessant, want toen was het verweer dat de fout gemaakt zou zijn door extern ingehuurde partijen die voor de IT moeten zorgen. Dat sluit precies aan bij het beeld dat ik schets: een organisatie die z'n IT uitbesteedt aan externe dienstverleners die allemaal hun eigen stukje doen zonder dat er mensen zijn die nadenken over het grotere plaatje of hoe al die onderdelen samenwerken.
Dat is geen hele gekke aanname want dat proces zie je momenteel overal. Waarschijnlijk is er wel ene kleine IT-afdeling maar die moet dan zowel zorgen voor inkoop, contracten, ondersteuning, beveiliging en techniek. Er zijn er niet veel die dat allemaal kunnen en de weinigen die het wel kunnen zijn onbetaalbaar. De mensen die gespecialiseerd zijn in die andere gebieden weten weer niks van IT.
Daarbij zal ik wel direct erkennen dat het ook niet makkelijk is om het wel goed te doen. De algemene kennis van IT is erg laag. Dan krijg je al snel de situatie dat 1 gek meer kan vragen dan 10 wijzen kunnen beantwoorden. We zullen het algemene kennisniveau flink moeten opvoeren en dat is een grote opgave.
Vandaar de conclusie waar ik dit stuk mee begon: dit gaat voorlopig niet goed komen. Zolang er over beveiliging wordt gedacht als een sausje dat je over je over je lauwe fast-food kan gooien om er een gezonde maaltijd van te maken gaat dit niet veranderen. Als de vitamines weg zijn en de burger is aangebrand dan komt het nooit meer goed, je kan de vieze smaak verbergen met veel saus maar het wordt nooit meer gezond.