Lek in verzuimsoftware gaf toegang tot gegevens 300.000 mensen

Door een lek in verzuimapplicatie Humannet waren de medische en andere persoonlijke gegevens van 300.000 werknemers van honderden organisaties waaronder de gemeente Deventer, de Praxis en de Bijenkorf te achterhalen.

Via het lek zou het eenvoudig zijn om inlognamen en wachtwoorden te achterhalen waarna toegang verschaft kon worden tot de databases met gegevens van duizenden werknemers van honderden bedrijven, zoals FC Twente, de gemeente Deventer, Praxis, Bijenkorf, V&D, Hornbach, Beter Bed en Action. Het zou onder andere om personeelsinformatie over adressen, verzuim, herstel en re-integratie gaan. Ook zouden medische dossiers van bedrijfsartsen en burgerservice-nummers te benaderen zijn, claimt Zembla. Het gaat om de database van Humannet van it-bedrijf VCD, dat vatbaar was voor sql-injectie.

Enkele kijkers zouden het lek opgemerkt hebben na een eerdere uitzending van Zembla, over privacyschending van het Hengelose bedrijf Verzuimreductie. Dat bedrijf maakte ook gebruik van Humannet en volgens kijkers zou een snelle blik op de verzuimapplicatie al laten zien dat deze vatbaar was voor sql-injecties. Een kijker liet daarop weten eenvoudig de databases van Humannet te kunnen benaderen.

Prof. Jacobs van de Radboud Universiteit Nijmegen verifieerde het lek: "We waren binnen een kwartier in het systeem en hadden daarmee controle over een beheersaccount. De toegang hiertoe is zo laagdrempelig, het is bijna uitlokking." Hij spreekt van 'het grootste lek van persoonlijke en medische data in de Nederlandse geschiedenis' en wijst op de mogelijkheden tot chantage als de gegevens in verkeerde handen vallen. It-bedrijf VCD heeft de drie 'zwakke plekken' inmiddels gedicht en zegt niet uit te kunnen sluiten dat er een geslaagde aanval heeft plaatsgevonden.

Reacties (113)

[Stef42]

Als men de uitzending van Zembla had gezien over Verzuimreductie, dan had je geweten dat de 'callcenter-medewerkers' niet alleen strikt noodzakelijke gegevens haalden van medewerkers van cliënten, maar tevens medische en psychologische gegevens. Gegevens die zij helemaal niet mogen vastleggen (link), want zij zijn geen medici. En nu liggen waarschijnlijk al die gegevens op straat. Dus wanneer iemand toegang zou krijgen tot deze 'gelekte' gegevens kan men lezen dat medewerker A van Praxis/V&D zelfmoordneigingen heeft (een voorbeeldje) of dat medewerker B is geopereerd aan....

[Reactie gewijzigd door Stef42 op 30 juli 2024 13:26]

[Sm0keZ]

De term 'verzuimsoftware' krijgt hier toch wel een erg dubbele betekenis.

[robinverl]

Ik mis de +1 grappig

[D-Day]

Ijzersterke opmerking inderdaad, epic

[Hoogevenertje]

Is het wettelijk niet mogelijk om dit soort bedrijven aan te pakken?
Dit is toch wel een ernstig verzuim van de privacy en veiligheid.

[Dennisdn]

Ik opteer ervoor dat niet de eigenaar, maar de hacker wordt aangepakt.
Als er bij mij thuis wordt ingebroken gaat men in principe ook achter de inbreker aan i.p.v. Mij een boete te geven voor de ondeugdelijke beveiliging. En ik kan maar niet begrijpen waarom dit in de cyber wereld precies andersom is.

[Juwayri]

Als jij iets waardevols achterlaat in een kluis bij de bank, dan ga je er van uit dat het veilig is en dat het niet weggehaald wordt.

Echter, als die bank wordt overvallen, en de overvallers krijgen simpelweg toegang tot die kluis waar iets van jou in ligt. Op wie wordt jij dan boos als ze het weghalen? De bank of de overvaller?

De bank geeft jou garanties gegeven dat het niet weg gehaald zal worden en moet zich daar aan houden. Dat werkt hier met persoonlijke gegevens ook zo. Je hebt in Nederland de plicht om persoonsgegevens veilig te stellen, en daar heb je je aan te houden. Die hackers zijn bijzaak. Die zijn ook verkeerd bezig en moeten zeker aangepakt worden. Maar als Hummanet de beveiliging goed op orde had gehad waren die hackers er niet eens bij gekomen.

[sys64738]

Misschien een gekke insteek maar is de opdrachtgever hier ook niet zelf verantwoordelijk?

In principe heb je gelijk maar het is in software-land al vaker gebleken dat je niet blindelings op it bedrijven kunt vertrouwen omdat er aardig wat rotte appels tussen zitten. Je zult dus als opdrachtgever toch ook zelf na moeten gaan hoe professioneel een leverancier is. Een bedrijf dat sql injecties toelaat in zijn software valt tijdens een kort gesprek echt wel door de mand op aspecten zoals security. Voor mijn werk zit ik vaak aan de kant van de opdrachtgever om op deze manier aanbiedingen/voorstellen op technische waarde te kunnen schatten.

Daarnaast hoop ik natuurlijk van harte dat dit soort bedrijven dermate goed aangepakt worden dat ze nooit meer grote/serieuze klussen kunnen doen. Sneu voor de mensen die er werken (maar die dus ook deze fouten gemaakt hebben) maar dit soort clubs moeten natuurlijk niet veel meer doen dan een website-je maken voor de lokale tafeltennisvereniging (en dan zeker niet de leden admin!).

edit: ik vind het trouwens grappig dat hier overal de vergelijking met banken gemaakt wordt. Dit is natuurlijk een scheve vergelijking want er zijn maar een paar banken in Nederland die allemaal aan strenge regels (moeten) voldoen. IT bedrijven komen en gaan en er zijn niet echt strenge regels of richtlijnen. Iedereen kan een it bedrijf beginnen en met een beetje geluk/pech de meest delicate projecten in de wacht slepen.

[Reactie gewijzigd door sys64738 op 30 juli 2024 13:26]

[freaky]

Mja wel iets genuanceerder. Als het nou echt een heel geavanceerde aanval was geweest dan kan ik me er nog iets bij voorstellen.

Maar clubs van deze orde met simpele SQL-injecties? Nee... die mogen ze afschieten. SQL-injecties zijn al jaren in het nieuws en je mag verwachten, nee eisen, dat ze dat weten en rekening mee houden.

[Erkens]

Maar clubs van deze orde met simpele SQL-injecties? Nee... die mogen ze afschieten. SQL-injecties zijn al jaren in het nieuws en je mag verwachten, nee eisen, dat ze dat weten en rekening mee houden.

Uiteraard, maar het is niet haalbaar om alle oude code per direct te herschrijven, daar is simpelweg de tijd en geld niet voor.
Voor nieuwe code en patches op bestaande code geef ik je helemaal gelijk, je moet er rekening mee houden, maar om alle oude code te reviewen is simpelweg niet haalbaar zonder enorme kosten terwijl het effectief niks op hoeft te leveren.

Zodra je het tegenkomt is het enige wat je kan doen zo snel mogelijk patchen.

[lammert]

Je overdrijft ernstig, zo duur is dat niet. Het enige dat nodig is om sql injectie te voorkomen is alle gebruikersinvoer opschonen en valideren. Kwestie van één klasse schrijven (of kopiëren, zijn in iedere taal zat te vinden) en daar alle gebruikersinvoer doorheen jagen. Bij vrijwel alle frameworks zijn deze klassen al ingebouwd. En hoeveel invoervelden heb je nou in een applicatie, dat zijn er echt geen tienduizenden. Iedere programmeur die dit niet standaard doet dient meteen ontslagen te worden, 10 jaar terug al, maar nu zeker.

De enige reden dat dit soort bedrijven kunnen bestaan is dat klanten zelf de ballen verstand hebben van ICT en veel te veel vertrouwen op de (ontbrekende) expertise van leveranciers...

[Ergomane]

Nee dus.

Validatie en opschonen raken misschien wel aan de mogelijkheid tot SQL-injectie, maar zijn uiteindelijk niet geschikt, noch bedoelt om SQL-injectie te voorkomen.

Daartoe dienen geparametriseerde queries te worden gebruikt, waarbij de data apart naar de dbserver wordt verzonden. Als die mogelijkheid niet beschikbaar is, kun je overwegen escaping te gebruiken, maar alleen op data die ook daadwerkelijk in een query wordt geplaatst.

Ga je data gebruiken om te mailen, of een bericht te tonen aan een gebruiker dan zul je weer hele andere stappen moeten volgen.

[Thc_Nbl]

Om hier niet een te grote discussie te veroorzaken..
sql injecties is heeeeeel simpel te beveiligen.

gooi voor je MS webserver een linux webserver, installeer apache en mod-security
en proxy je website via apache naar je ms webserver.
klaar ben je nooit meer sql injecties.

So simpel, ja het is om je brakke code heen gaan, maar wel altijd beveiligd.
zo heb ik nog joomla 1.0 tot nu draaien met alle leks in de sites, maar door mod security goed te gebruiken hoef je wat minder op je code te letten en al 8 jaar geen hacks meer gehad en ja ook niet goed, maar het scheelt bergen gezeik.

[Reactie gewijzigd door Thc_Nbl op 30 juli 2024 13:26]

[Ergomane]

Misschien moet je even http://blog.php-security....-Modsecurity-vs.-PHP.html en de links daarin lezen.

[VVV-007]

nou volgens mij is het toch heel eenvoudig om als groot databeheer bedrijf (want daar gaat het wel om als er 100-en bedrijven hun administratie in jouw systemen/software hebben staan) eens zelf een paar sql injecties te doen op je eigen programatuur en als je er dan achter komt dat het zo lek is als het maar kan, dan had je wel actie moeten ondernemen lijkt mij. Dit is nou niet de eerste keer dat sql injecties in het nieuws zijn, dus als ze er serieus mee bezig waren geweest, ook al is het oude programatuur, dan hadden ze er al moeten werken. (ze hebben nu nadat dit in het nieuws is ook al 3 lekken gedicht, dus blijkbaar gaat het wel redelijk makkelijk, dus dat had gewoon al lang gebeurt moeten zijn.

je mag van dergelijke bedrijven wel verwachten dat ze hun systemen bijhouden en indien nodig aanpassen aan de huidige tijd.

[Wim-Bart]

[...]

Uiteraard, maar het is niet haalbaar om alle oude code per direct te herschrijven, daar is simpelweg de tijd en geld niet voor.
Voor nieuwe code en patches op bestaande code geef ik je helemaal gelijk, je moet er rekening mee houden, maar om alle oude code te reviewen is simpelweg niet haalbaar zonder enorme kosten terwijl het effectief niks op hoeft te leveren.

Zodra je het tegenkomt is het enige wat je kan doen zo snel mogelijk patchen.

In de huidige nieuwsgeving komen dit soort inbraken bijna dagelijks aan het licht. Wat veel erger is dat een bedrijf in de basis al op het simpele inlogscherm al gevoelig is voor SQL injection. Dit kan dan ook gezien worden als een faal dat ze al geen fix hadden op deze basale functionaliteit.

Daarnaast ben ik zelf vanuit een aantal klanten al met dit product in aanraking gekomen en heb ik mijzelf al vaak afgevraagd hoe veilig dit is, ook wel eens ter discussie gesteld. Maar ik vraag me af hoe veel vertrouwen je moet hebben in een bedrijf dat "performance" problemen afwenteld op de internet verbinding van de klant en nu dit soort problemen heeft. Het lijkt er op dat ze gewoon alleen maar cashen en zo min mogelijk kosten willen maken zonder echt rekening te houden met de klanten,

[Dipsausje]

Niet helemaal. Een voorbeeld: als jij je geld toevertrouwd aan de bank, en de bank laat vervolgens de kluisdeur op een kier staan dan wil de bank ook verantwoordelijk wordt gehouden.

In het geval van bank+kluis is het makkelijk: je wil het gestolen geld dat je hebt toevertrouwd aan de bank terug hebben. In het geval van deze gegevens is het lastiger, immers ben jij niets kwijt alleen hebben anderen opeens wel privacygevoelige informatie van jou in handen. Het bedrijf heeft is hier niet verantwoord met de gegevens die hen in vertrouwen zijn gegeven omgegaan. Ik ben van mening dat je bedrijven hierop zeker moet kunnen aanpakken.

Let wel: bedrijven aanpakken wanneer zij de hen toevertrouwde gegevens onvoldoende beveiligen betekent niet dat je niet ook de inbrekers aanpakt. Het lastige hierin is dat sommige inbrekers (Prof. Jacobs in dit geval bijvoorbeeld) met een goede reden inbreken, als zij het niet doen dan weet niemand van het lek en dan kunnen criminelen er mee vandoor gaan zonder dat iemand het door heeft.

Wat dat betreft zou het misschien een idee zijn (vooral voor systemen waar zoveel privacygevoelige data staat) om het systeem niet enkel intern te testen maar, gevuld mt onschuldige testdata, online te gooien en er zoveel mogelijk mensen op los te laten. Schrijf een beloning uit per gevonden lek en voilà, dit soort stomme beveiligingsfouten worden gevonden zonder dat er meteen gegevens van duizenden mensen op straat komen te liggen.

[Anoniem: 195780]

[bwerg]

Ik opteer ervoor dat niet de eigenaar, maar de hacker wordt aangepakt.
Als er bij mij thuis wordt ingebroken gaat men in principe ook achter de inbreker aan i.p.v. Mij een boete te geven voor de ondeugdelijke beveiliging.

Maar als het geen inbraak in je huis is, maar insluiping (dus je hebt de deur niet op slot terwijl je niet thuis was), dan is de strafmaat al minder. Zet je je dure spullen in de tuin achter een hekje van 30cm hoog, dan zal dat zelfs geen insluiping zijn maar "slechts" diefstal, omdat de inbreker niet eens moeite heeft hoeven doen om bij je spullen te komen, en reken er ook maar niet op dat de verzekering iets uitbetaald omdat je zelf gewoon nalatig bent geweest. En SQL-injecties zijn al sinds SQL1.0 (ruim 20 jaar) bekend en verplichtte stof voor elke informaticus die er iets mee doet, en daarom wel vergelijkbaar met een beveiliging d.m.v. tuinhekje.

En ter informatie: uitlokken van diefstal kan je zeker wel een boete voor krijgen (bijvoorbeeld een fiets niet op slot zetten). Gebeurt niet vaak, maar mag m.i. wel vaker bij beveiliging van tuinhekjes-niveau. Daarnaast is het moreel gezien nogal een verschil of jij achteloos je eigen spullen laat stelen (je eigen probleem, al kan dat dus al een boete voor jou opleveren), of je beheert andermans spullen (of gegevens) en die laat je stelen. Zoals in dit geval, en bijna alle gevallen van hacks die op tweakers gemeld worden.

En ik kan maar niet begrijpen waarom dit in de cyber wereld precies andersom is.

Daarnaast is het ook nog eens zo dat er in de cyber-wereld geen sociale controle is, die je wel hebt in een gemiddelde woonwijk. Zet je in een flat je deur open en wordt er ingeslopen, dan heb je grote kans dat medebewoners dit merken en insluiping of inbraak wordt (eventueel achteraf) altijd ontdekt. Het bestraffen van de inbreker heeft hiermee een preventieve werking, omdat hij ontdekt kan worden. Op internet heb je dit niet, zodra een website lek is kan de hele wereld erbij en je hebt geen idee wie deze database allemaal geplunderd heeft. Achter hackers aan gaan heeft dus geen enkele preventieve werking, het is meer een mazzeltje als je toevallig een hacker ontdekt maar zelfs als je zo iemand vind, dan heb je geen idee wie er nog meer deze database heeft geplunderd. De enige manier om een website goed te "verdedigen" is door inbreken überhaupt onmogelijk te maken, en dat weet iedereen met een beetje verstand van digitale veiligheid. Dat zouden websitebeheerders dus ook moeten weten, zij zijn verantwoordelijk voor deze databases.

[Reactie gewijzigd door bwerg op 23 juli 2024 19:45]

[robinverl]

Deels heb je gelijk, anderzijds is het wel zo dat er bij wijze van niet eens sloten op je deur zitten. De inbreker is fout, maar jij gaat ook nooit meer iets terugzien van je verzekeraar!

[David Mulder]

Omdat de hacker niets anders doet als vanaf straat wat rond te roepen en kijken hoe het huis er op reageerd (wat totaal nergens op slaat in de echte wereld, maar dat is wel hoe de quote:"cyber wereld" werkt). Als hij er daarna misbruik van maakt dan is het logisch dat je hem gaat vervolgen natuurlijk, maar dat zou los moeten staan van bijv. een kijker die op tv direct al merkt dat ze... weet ik veel... een select statement in de url letterlijk meesturen ofzo.
Daarnaast, om weer terug te gaan naar de echte wereld allegorie, als jij van allemaal bedrijven de boekhouding in je huis hebt liggen, en er word bij je ingebroken (foute vergelijking eigenlijk, want eigenlijk laat je de gegevens bij de hacker thuisbezorgen nadat hij d'r om vraagt maar dat is een andere discussie) en achteraf blijkt dat alle deuren niet op slot zaten, dan kun je ook een flinke claim verwachten.

[Teckna]

Oneens, een 'hacker' die een beveiligingslek constateert en deze doorgeeft aan de juiste instanties om deze te repareren (inclusief media) hoeft voor mij niet vervolgt te worden maar denk dat een zogenaamde klokkenluider status er beter bij past. Wat ik wel graag zou willen zien is een meldplicht naar het bedrijf in kwestie toe zodat deze ook de kans krijgt ze te repareren.

Een 'hacker' die het doel voor ogen heeft gegevens te misbruiken / verkopen / destructie en al dat soort dingen mogen van mij prima (hard) aangepakt worden, zeker als het om medische gegevens gaat.

Het grootste probleem hier is dat deze lek er waarschijnlijk al erg lang in heeft gezeten en niemand weet of iemand er überhaupt misbruik van heeft gemaakt voordat deze klokkenluider heeft aangegeven dat de beheerder zijn zaakjes op orde moet hebben.

Dat de klokkenluider in dit geval eerst naar de media stapt dan het bedrijf in kwestie snap ik ook wel. de verzuimpolitie is erg negatief in het nieuws geweest over werkwijze die wettelijk eigenlijk niet eens grond hebben en dit is zijn 3 minutes of fame

[Ergomane]

Dat hangt ervan af of de "inbraak" proportioneel is.

Als je bijvoorbeeld een SQL injectie constateert, dan kun je dat gewoon melden. Een dump van de database maken, of tientallen medische dossiers inzien is niet nodig en gaat IMO veel te ver.

[Anoniem: 126610]

Het gaat pas te ver als je die dossiers/dumps online zet.

Tot die tijd fungeren de dumps slechts als bewijs dat het lek bestond. Wat je anders krijgt is dat het bedrijf het lek dicht en kan zeggen dat het nooit bestaan heeft terwijl de kans reeel is dat een kwaadwillende al lang de beschikking heeft over de complete gegevensset. Er zijn vele, vele, vele voorbeelden van bedrijven die ontkennen dat gegevens gestolen (kunnen) zijn, totdat de hacker bewijs online zet. Dat heet liegen en daar hou ik niet van.

Waar ik wel van houu zijn goedwillende hackers die beveiligingen testen en kwetsbaarheden melden. Zij voorkomen (als het bedrijf actie onderneemt) dat kwaadwillenden (nog langer) met mijn gegevens aan de haal kunnen gaan.

Als je die goedwillende (white hat) hackers wilt gaan vervolgen, zullen ze vanzelf uitsterven.

Dan hou je alleen de kwaad willende hackers over en wordt er nooit meer 1 lek gedicht.

[Hoogevenertje]

Uiteraard moet men de hacker ook vervolgen, maar dit vind ik zeer zeker een grove nalatigheid van dit bedrijf.

[Bio1ogics]

En als er in jouw huis nu spullen van een ander staan, waar jij het beheer over hebt. Mogen de eigenaren van die spullen misschien even aan jou vragen of je de boel wel op slot had?
Als jij alles netjes hebt geregeld, valt je weinig te verwijten. Als het raampje openstond, mag je wmb ook aangepakt worden.

[Teijgetje]

Volgens mij ben je strafbaar als je bv je auto met draaiende motor en sleutels erin laat staan en even wegloopt.........

Zo zie ik die lekken deels ook, "we hebben de boel draaiende maar zijn even met wat anders bezig dan de zij- en achter-deuren op slot te doen", zero day lekken uitgezonderd.
Hoe moeilijk is het om, op regelmatige basis, onafhankelijke hackers in te huren om beveilligingsproblemen op te sporen?
Of voelen de hh bedrijfs-ICT-beveiligers zich daar te groot voor, om toe te geven dat er enkelen zijn die meer skills hebben dan zij?

Lijkt mij, anno 2012, standaard in een businessmodel zitten van bedrijven die met gevoelige (prive)informatie omgaan.

En inderdaad, IMHO, bestraffen als blijkt dat ze hun beveiliging niet op orde hebben.

"Met de tijd meegaan" heet dat geloof ik, met een moeilijk ICT woord.
(want draait het, dan draait het, dus niks meer aan doen...)

[Reactie gewijzigd door Teijgetje op 30 juli 2024 13:26]

[TDeK]

En ik kan maar niet begrijpen waarom dit in de cyber wereld precies andersom is.

Omdat in de echte wereld vrijwel iedereen een goed deurslot kan installeren, terwijl online de gewone sterveling een bedrijf in de arm neemt om een site te bouwen, waarbij ze er vanuit gaan dat die weten wat ze doen. Dat is hetzelfde als een bedrijf je huis laten beveiligen en er vervolgens achterkomen dat er geen ramen in de kozijnen zitten. Tja, kun je dan de dief nog kwalijk nemen dat hij er met je huisraad vandoor gaat? Je hebt zelf ook een verantwoordelijkheid.

[blouweKip]

Denk je dat je verzekering uitbetaald als jij je deur open had staan terwijl je niet thuis was?

[Tarabass]

Welke hacker? Dus als ik jou wijs op het openstaan van jouw kluis met inhoud, moet ik aangepakt worden omdat ik gekeken heb of hij openstaat? Rare beredenering..

[twooggy]

In de trant van het 'open huis'. Als er iemand jou er op wijst dat je deuren staan, bedankt je zo iemand toch ook even ipv hem te vervolgen wegens huisvredebreuk?

[Niemand_Anders]

Maar als de aannemer de voordeur niet vastzet waardoor deze omvalt wanneer je er tegenaan leunt, dan spreek je de aannemer er wel op aan!

Of als het Balkon ineens afbreekt.

In dit geval is er een web applicatie gemaakt waar gewoon structurele fouten in zitten. Wat mij betreft mag er een boete komen van 500 euro per NAW gegeven als deze uitlekken.

En met een beetje geluk hebben we dan binnen 3 maanden het begrotingstekort opgelost. Als de overheid het dan een beetje goed aanpakt hebben we het begrotings tekort snel weggewerkt.

Waarom het in de cyberwereld precies andersom is? Als er bij jouw wordt ingebroken hebben ze alleen de NAW gegevens van een beperkt aantal personen. Als er bij een website wordt 'ingebroken' liggen er al snel tien duizenden NAW gegevens op straat.

Wordt je gehacked door een zero-day-exploit dan heb je pech, maar als gegevens uitlekken door een SQL/XSS injection lek is dat gewoon grote nalatigheid van de partij welke de website heeft gemaakt.

In dit geval zou de boete dan naar Humannet moeten gaan en zij moeten intern de boete doorsturen naar VCD welke de website heeft gemaakt..

[Standeman]

*knip*

Eerst F5, dan pas posten. Dipsausje was een stuk eerder

[Reactie gewijzigd door Standeman op 30 juli 2024 13:26]

[Sundog]

Ik opteer ervoor dat niet de eigenaar, maar de hacker wordt aangepakt.
Als er bij mij thuis wordt ingebroken gaat men in principe ook achter de inbreker aan i.p.v. Mij een boete te geven voor de ondeugdelijke beveiliging. En ik kan maar niet begrijpen waarom dit in de cyber wereld precies andersom is.

Het gaat in dit geval volgens mij vooral om verantwoording en aansprakelijkheid, niet om schuld.
De bedrijven die gebruik maken van deze "applicatie", mogen persoonlijke gegevens verwerken en opslaan, en accepteren daarmee de verantwoording dat ze deze gegevens op een manier opslaan die redelijkerwijs bescherming bied tegen misbruik door derden.
Die verantwoording kan je niet zo maar afwentelen op een applicatie leverancier, hoewel daar zonder meer de "root cause" ligt.

Het selecteren van de juiste applicatie en juiste leverancier maakt, in mijn ogen, onderdeel uit van die verantwoordelijkheid.
Dat die bedrijven op hun beurt de leverancier en beheerder aansprakelijk kunnen stellen is een ander verhaal.

[BoringDay]

Het blijft mensenwerk ... je weet hoe mensen zijn he? we maken namelijk wel eens fouten. Als men doelbewust met opzettelijk kwaad dit deden dan vind ik aanpakken.

Wat als mensen straks geen fouten meer mogen of kunnen maken? stel jij op je werk geen enkel fout mag maken en meteen rechtszaak aan je broek krijgt?

Hoeveel mensen zullen er dan nog straks werken? ik denk geen 1

[bzerk]

Dit is geen foutje. Dit is nalatigheid.
Het is helemaal geen grote moeite om je website ongevoelig te maken voor SQL injection. Dit moet gewoon bij het ontwerp meegenomen worden. Zeker bij een bedrijf die handelt in dit soort informatie.

[BoringDay]

lol ... dat weet ik zelf ook nog wel maar volgens mij ging het hier om een inlog procedure .
Ik zie nergens staan dat het hier om een SQL injectie gaat dat is een draai die je er zelf aangeeft.

[Xenan]

Dit is niet zomaar een foutje, kwestbaarheid voor SQL injectie is zeer amateuristisch en vergelijkbaar met grove nalatigheid.

[TDeK]

Wat als mensen straks geen fouten meer mogen of kunnen maken? stel jij op je werk geen enkel fout mag maken en meteen rechtszaak aan je broek krijgt?

Als ik een database met 300.000 zeer gevoelige records erin moet bouwen, dan laat ik daar zeker meerdere mensen naar kijken, laat ik desnoods een externe partij de security testen en vervolgens blijf ik hem monitoren als het live staat. Het lijkt er hier eerder op alsof een stagiar die database (en site) heeft gebouwd, dat niemand de code heeft gecontroleerd, en als dat wel is gebeurt dan is het bedrijf volledig incompetent en mogen ze van mij Diginotar achterna (binnen enkele weken failliet).

[bwerg]

Het blijft mensenwerk ... je weet hoe mensen zijn he? we maken namelijk wel eens fouten. Als men doelbewust met opzettelijk kwaad dit deden dan vind ik aanpakken.

Stel dat iemand in een garage eigenlijk helemaal geen verstand heeft van auto's, en toch aanbied om de wielen te verwisselen, zonder te vermelden dat hij niet weet wat hij doet. Hij kan er geen moer van en de wielen zitten helemaal niet vast, maar hij heeft zijn best gedaan (dit is ongeveer het niveau van een beveiliging die vatbaar is voor SQL-injectie). Als er dan slachtoffers vallen, dan is dat gewoon "een foutje" van de garage? Als je ergens geen verstand van hebt, moet je d'r niet aan beginnen, of in ieder geval zorgen dat je geen eindverantwoordelijke bent zodat iemand je werk controleert.

Dat heeft te maken met nalatigheid. Iedereen heeft verantwoordelijkheden, en als je die niet serieus neemt kan je dat ook verweten worden. Ik weet niet wat je technische kennis is, maar een SQL-injectie zou ik al niet accepteren in een schoolopdracht van een eerstejaars HBO'er, laat staan van een professioneel bedrijf dat aanbied gevoelige informatie te beheren.

[Reactie gewijzigd door bwerg op 30 juli 2024 13:26]

[BoringDay]

Leuk en aardig maar weet je dan ook wat de fout is?
Ik weet ook wel dat je SQL injecties kan afvangen.

En ik zie tevens niet in wat dit met HBO-ers 1e jaars te maken heeft, je hebt geen HBO nodig om een database te kunnen programmeren hoor. Dat kan iedere kip die zich erin gaat verdiepen.

Maar hoe kan je iets nalatigheid noemen als je niet eens weet wat de fout was?
Misschien stond er wel 1 karakter niet goed in duizenden regels code .... dat overkomt ook de beste wel eens.

[bwerg]

En ik zie tevens niet in wat dit met HBO-ers 1e jaars te maken heeft

Daarmee wil ik zeggen dat het echt een basis-ding is.

, je hebt geen HBO nodig om een database te kunnen programmeren hoor. Dat kan iedere kip die zich erin gaat verdiepen.

Ja, dat is ook het probleem. Natuurlijk mag je dat ook zonder HBO-diploma, maar dan moet je wel zorgen dat je een eventueel gebrek aan kennis of ervaring afvangt. Wat nog te vaak gebeurt is dat iemand 'zijn handige neefje'* iets vraagt te doen en zich niet realiseert dat dat neefje eigenlijk niet in staat is om het wel op een professionele manier te doen. En zelfs al is iemand zich daar wel van bewust, het hele gedoe met uitgebreid testen e.d. wordt te vaak onderschat.

*en daarmee bedoel ik niet alleen echt neefjes, maar ook kundige mensen die even iets doen waar ze eigenlijk geen ervaring mee hebben, beveiliging bijvoorbeeld.

Maar hoe kan je iets nalatigheid noemen als je niet eens weet wat de fout was?
Misschien stond er wel 1 karakter niet goed in duizenden regels code .... dat overkomt ook de beste wel eens.

Hoe kan je iets bij voorbaat wegwuiven als je niet weet wat de fout was? En ja, je hoort je software te testen. In echt kritieke software hoort vaak meer uren aan test-werk te zitten dan in het daadwerkelijk implementeren. Ja, het kan eens misgaan, maar als er persoonsgegevens van 300.000 achter zitten dan vind ik de mogelijkheid tot SQL-injectie gewoon een te grove fout. Als iemand van de 50-plus-partij dit kan vinden, dan had een tester het ook moeten vinden.

Daarnaast lees ik hier ook al reacties van mensen die er wel iets meer inzichtin hebben, en dat zegt wel iets. Dit soort fouten komt eerder door een te lakse houding dan door een professional die, ondanks zijn waterdichte procedures en testmethodes, toch een klein foutje maakt. Zie ook de reacties in het artikel:

en volgens kijkers zou een snelle blik op de verzuimapplicatie al laten zien dat deze vatbaar was voor sql-injecties. Een kijker liet daarop weten eenvoudig de databases van Humannet te kunnen benaderen.

Prof. Jacobs van de Radboud Universiteit Nijmegen verifieerde het lek: "We waren binnen een kwartier in het systeem en hadden daarmee controle over een beheersaccount. De toegang hiertoe is zo laagdrempelig, het is bijna uitlokking.

Dat zegt hij niet als de NSA met grote moeite is ingebroken...

[Reactie gewijzigd door bwerg op 30 juli 2024 13:26]

[cbravo2]

Als je met zeer gevoelige data werkt dan is het toch roekeloos om je niet aan de algemeen verkrijgbare ict beveiligingsrichtlijnen webapplicaties te houden? Je had dat toch kunnen weten?

Dat hackers veroordeeld kunnen worden wisten we al. Maar de voordeur open laten staan? Volgens mij moet er een keer een bedrijf worden veroordeeld om voor security meer prio te krijgen.

edit: verduidelijking.

[Reactie gewijzigd door cbravo2 op 23 juli 2024 08:08]

[D-Day]

Volgens mij mag je je eigen voordeur open laten staan, iig niet strafbaar. In mijn ideaalbeeld van een samenleving moet dat ook kunnen btw...
Maar niet als je de bank bent of verantwoordelijkheid draagt voor de gegevens van 300.000 mensen. Da's immoreel indien bewust niet beveiligd, of heel heel erg dom wanneer dit onbewust is gedaan.
Zoals de professor al zegt: mensen (300.000 dus) kunnen met deze gegevens worden gechanteerd of anderzins benadeeld, de gevolgen zijn niet te overzien. En dan stelt het beveiligingsbedrijf dat er geen garantie gegeven kan worden dat een aanval niet is geslaagd! OMG, dit gaat goed mis voor die jongens...

Ik werk bij een soortgelijke organisatie, maar als gebruiker, niet bij de IT. Ik heb wel contact met ze opgenomen met het verzoek/vraag of ons systeem ook eens door externen getest kan worden/of dat dat al is gebeurd...

EDIT: check, ben net gebeld dat toename van aanvallen zijn gesignaleerd en daarbij wordt het voorstel hoger in de organisatie opgepakt, krijg nog een update...

[Reactie gewijzigd door D-Day op 30 juli 2024 13:26]

[twooggy]

Oftewel, ook in jouw organisatie is e.e.a. nog niet op orde?

[bwerg]

Ook een systeem waar vol vertrouwen in is dient zo nu en dan gecontroleerd te worden, natuurlijk. Ja, veel bedrijven doen dit pas als het spreekwoordelijke kalf verdronken is maar een bedrijf dat beveiliging een beetje serieus neemt test die beveiliging natuurlijk sowieso, ook al zijn er geen concrete aanwijzingen dat er ingebroken is.

[D-Day]

Dat laatste dus, ze nemen het serieus en er is niet ingebroken, wel geprobeerd.

[Perkouw]

En weer 300.000 gegevens op straat alsof het niet is. Ik vind het een behoorlijk kwalijke zaak dat een IT bedrijf welke is toevertrouwd met zo'n hoeveelheid, privacy gevoelige, gegevens vatbaar is voor een simpele SQL injectie. 15 minuten maar om in het systeem te komen, echt schandalig.

Ik hoop voor de 'getroffen' mensen dat er geen data is buitgemaakt/verspreid. Ik ben bang dat het bij hopen blijft, zeker zul je het niet weten totdat het misbruikt word o.i.d.

[2Dutch]

Er moet nu toch wel iemand in de politiek zoiets hebben van "wacht eens even, er lekt overal persoonlijke data op het web in dit landje, tijd dat we er eens kritisch naar gaan kijken".

Ook vanuit de branche zelf kan ik me voorstellen dat dit zorgt voor een beroerd imago: Ben benieuwd wat hier voor een verdere berichtgeving op volgt, meestal hoor je hier nooit meer wat over Juist blijven communiceren hierover blijft belangrijk. Helaas wordt het erover hebben vaak eerder als zwakte dan als positief punt gezien, ook een drempel als je het mij vraagt..

[TDeK]

Ik blijf het zeggen: het wordt tijd dat er wetgeving komt die dergelijke bedrijven strafbaar kan stellen wegens grove nalatigheid en voor schadeloosstelling van de gedupeerden. Anders leren ze het nooit. Ze laten het testen en security liever liggen dan dat ze een iets hogere aanbesteding moeten uitgeven, met alle gevolgen van dien. En van 'overmacht' (daar gooien ze het vaak op) is hier geen sprake, aangezien SQL injection gewoon heel simpel te voorkomen is.

[Dostar]

Erger nog is vaak het zoethoudertje dat bedrijven en instanties dan terug geven om de eventuele schade te verhelpen.

Zoals Sony Playstation na een hack waarin creditcard gegevens e.d. vrij kwamen die dan doodleuk 2 gratis games weg geeft als zoethouder, wat totaal niet in verhouding staat tegenover eventuele (financiele) schade.

Ik ben het ook helemaal met je eens dat er een wetgeving moet komen waarin goede digitale veiligheid (voor persoonsgegevens) verplicht wordt ipv een vrije keuze.

Het woordje 'overmacht' en 'sorrie' wordt idd ook TE vaak gebruikt.

[Rctworld]

Sorry hoor, maar er zijn geen concrete aanwijzingen dat de creditcard gegevens die bij Sony "mogelijk" gestolen waren ook echt zijn misbruikt. Daarnaast heeft Sony alle credit card gegevens die mogelijk zouden gestolen zouden kunnen zijn gecommuniceerd met de creditcard maatschappijen en iedereen gratis een jaar lang identiteitsbeschermingsprogramma's gegeven.

Sowieso ben je als creditcard houder goed beschermd en een nieuwe aanvragen is gratis. Ik wil het niet goed praten wat er bij Sony gebeurd is, maar het grootste nadeel voor de meeste klanten was dat het netwerk er een maand lang uit lag...

[Dostar]

Het identiteitsbeschermingsprogramma was idd een erg mooie compensatie, was die zelf bijna vergeten omdat ik altijd aankopen doe met tegoed kaarten (veiliger imo). Een betere compensatie dan gratis games.

Het netwerk dat eruit lag heb ik zeer zeker gemerkt, had toen pas net een PS3 gekocht voor de nieuwe Mortal Kombat en voor Demon Souls, eerste spel kon ik mijn pre order DLC niet activeren, en 2e spel kon ik helaas het online gedeelte niet spelen.

Ik moet overgens wel bekennen dat ik blij ben met de gratis spellen die ik kreeg.

[pkopf]

Dan heb je inderdaad de technische kant te pakken, maar aan de gebruikerskant is ook nog e.e.a. te verbeteren. Was eerder deze week niet een bedrijf uit Noord Brabant in het nieuws, waar iedereen kon inloggen met accountnaam en wachtwoord '12345 '?
Hoewel die account waarschijnlijk als testaccount is gebruikt en hiervan nog steeds de ontwikkelaar als schuldige is aan te wijzen, verbaas ik me nog al te vaak over het soort wachtwoorden dat mensen gebruiken voor systemen. Een wachtwoord in de trant van 'naam van de hond' of 'geboortedatum' wordt nog vaak gebruikt. Daar kan een leverancier van een SaaS oplossing niet direct iets aan doen, als de afnemer een zwak wachtwoord kiest.

[Dakdoef]

Dit ben ik met je eens. Het is niet altijd de leverancier die er iets aan kan doen. Aan de andere kant, als je het hebt over wachtwoorden. Je kunt ook een systeem inbouwen dat wachtwoorden als 12345 verbiedt. Ook dat is niet heel moeilijk in te bouwen. Je wordt dan gedwongen om hoofdletters, cijfers, leestekens te gebruiken.

Vaak wordt dit echter niet gedaan, omdat de "gemiddelde" gebruiker het veeeeel te moeilijk vindt om wachtwoorden te onthouden. Daar wordt vaak ook wel weer iets op gevonden. Ben wel eens bij een (overheids)organisatie geweest voor een presentatie waarbij ik gebruik mocht maken van een laptop van daar. Toen ik om de inlog vroeg werd er gezegd: die staat op het briefje bovenop de laptop...... Als ik had gewild had ik zo op het hele netwerk kunnen komen...

[TDeK]

Als ik had gewild had ik zo op het hele netwerk kunnen komen...

Ik heb bij een bank gewerkt, en een collega van me heeft dit eens gedaan. Die kon dezelfde dag nog vertrekken. Er zijn dus ook plekken waar het wel heel netjes en goed geregeld is (tot op het versnipperen van kantoorpapier aan toe). Kortom, het gaat erom hoe serieus je je eigen werk neemt, en schijnbaar schort het daar nogal aan bij vcd (komt op mij over als een grote club consultancy cowboys).

Pas als ze persoonlijk risico lopen bij aantoonbare nalatigheid zullen mensen zich wel twee keer bedenken.

Dat weet ik niet, volgens mij kun je dan voor bepaalde systemen (belastingdienst, ziekenhuis, vliegtuig enz) gewoon geen mensen meer vinden. En als baas wil je dat ook niet, want als mensen alles op eigen titel doen dan kan er geen sprake meer zijn van werkweigering, immers wie is er dan verantwoordelijk voor wie. De boete moet op bedrijfsniveau binnenkomen, immers doen werknemers in 9 van de 10 gevallen taken die van hogerhand zijn opgelegd (zij halen de klant binnen, stellen de specs vast enz). Je doet zoiets ook altijd met meerdere mensen, dus wie is dan voor hoeveel Euro aansprakelijk in het geval van een fuckup? Dat wordt mijns inziens een moeilijk vraagstuk.

[Reactie gewijzigd door TDeK op 30 juli 2024 13:26]

[Anoniem: 126610]

Ik heb jarenlang bij een grote ziektekostenverzekeraar gewerkt. Daar kon je ook gewoon de gegevens van jan en alleman inzien. En geen haan die daar ooit naar kraaide.

Ik kan me een geval herinneren waarbij een dame zich ernstig zorgen maakte omdat haar man tijdelijk bij ons gedetacheerd zou worden. Deze vrouw had kort daarvoor een abortus ondergaan en was bang dat haar man in haar dossier zou kijken en dit zou zien (de bevruchting was niet door haar eigen man geschiedt). Dit viel inderdaad niet uit te sluiten.

Los van wat je moreel gezien van zo'n geval vindt, is het haar leven, haar huwelijk en haar buik. En haar medisch dossier, wat niet door onbevoegden ingezien zou mogen worden.

Geef mij 300.000 patiendossiers en ik weet daar wel een paar honderd chantabele gevallen uit te halen.

Ik denk dat het persoonlijk strafbaar stellen van de verantwoordelijken de enige manier is om dit soort lekken te voorkomen. Zolang 'het bedrijf' de boetes betaalt is het belang eenvoudigweg te klein. Pas als ze persoonlijk risico lopen bij aantoonbare nalatigheid zullen mensen zich wel twee keer bedenken.

[Reactie gewijzigd door Anoniem: 126610 op 30 juli 2024 13:26]

[ANW]

De veiligheid van "het systeem" is dus de "technische" veiligheid én de "menselijke" veiligheid. En een ketting is zo sterk als de zwakste schakel.

Het technische zal er voor moeten afdwingen dat het menselijke deel aan minimumeisen voldoet maar óók ervoor zorgen dat het menselijk deel dit kán doen.

Dus hoe krijg je sterke wachtwoorden die ook nog door een sterveling te onthouden zijn?
Met verschillende wachtwoorden voor verschillende systemen, die allemaal regelmatig gewijzigd moeten worden?

[locke960]

RSA tokens ipv wachtwoorden ?

Maar er zijn vele manieren waarop het beter kan. uit de losse pols:
- gebruiker opent de webpagina.
- Java VPN client app wordt gestart.
- gebruiker logt in op VPN met behulp van RSA token.
- er wordt een remote desktop sessie gestart, via de VPN tunnel, naar de applicatie server.
- gebruiker logt in op applicatie server.
- In de remote desktop sessie draait de web applicatie. (of iets anders, kan ook)

Vast ook niet 100% veilig, maar de kans dat een willekeurige vreemdeling in staat is bij de gegevens te komen is alvast vele malen kleiner.

Een goede beveiliging bestaat niet uit het proberen foutloos te programmeren. Dat is tot mislukken gedoemd. Een goede beveiliging bestaat in eerste instantie uit een goed doordacht beveiligingsconcept en de bereidheid het nodige geld uit te geven

En daar zit dus het echte probleem. Het verlangen alles zo goedkoop mogelijk te doen om zoveel mogelijk winst te maken, waarbij de beslissers niet dezelfde zijn als de potentiele slachtoffers.
(beslissers: ICT leverancier, verzuimbedrijf en werkgevers. slachtoffers: werknemers)

Ik noem dat criminele nalatigheid. Iedereen met een beetje verstand van IT weet dat er ALTIJD een behoorlijk hoog risico is als je een webserver "naakt" aan het internet hangt, zelfs met heel goede software.

[Grrrrrene]

Was eerder deze week niet een bedrijf uit Noord Brabant in het nieuws, waar iedereen kon inloggen met accountnaam en wachtwoord '12345 '?
Hoewel die account waarschijnlijk als testaccount is gebruikt en hiervan nog steeds de ontwikkelaar als schuldige is aan te wijzen, verbaas ik me nog al te vaak over het soort wachtwoorden dat mensen gebruiken voor systemen.

Een wachtwoord in de trant van 'naam van de hond' of 'geboortedatum' wordt nog vaak gebruikt. Daar kan een leverancier van een SaaS oplossing niet direct iets aan doen, als de afnemer een zwak wachtwoord kiest.

Hoe moeilijk is het om als ontwikkelaar een bepaalde password policy in te voeren? Minimaal 8 tekens, een mix van hoofdletters en kleine letters, minstens 1 cijfer en 1 bijzonder teken als _ % ^ # enzovoorts... Dan voorkom je dat domme gebruikers 12345 als wachtwoord kiezen. Het is niet leuk, maar je bent als ontwikkelaar wel verantwoordelijk voor wat je mogelijk maakt.

Zo'n password policy hebben we hier op werk zelfs, terwijl ik me afvraag wie ons zou willen hacken. Alle wachtwoorden zijn sterke wachtwoorden, worden ieder halfjaar ververst en mogen vervolgens niet op het volgende wachtwoord lijken. Ik snap niet dat die zogenaamde gerenommeerde organisaties die voor de overheid mogen werken (want staat van dienst is indrukwekkend) dit soort prutswerk durven/mogen afleveren.

[Reactie gewijzigd door Grrrrrene op 30 juli 2024 13:26]

[SPee]

Alleen wanneer ze zo'n policy opleggen, doen ze er ook een maximum aan tekens bij.
Dan krijg je van die rare constructies voor de wachtwoorden waar gebruiker niet blij van worden.
Een SSO oplossing is dan een stuk beter.

[Davio]

En als de wachtwoorden te moeilijk worden voor gebruikers om te onthouden, gaan ze het opschrijven op post-its die ze gewoon op hun scherm plakken. Even binnenlopen en doen alsof je een pakketje komt bezorgen (voor de buren, maar je hebt het verkeerde adres) en je weet het.

[leuk_he]

Dan blijft het punt dat er weggeving moet komen om dit aan te pakken.

Grootste probleem: Wie gaat dit handhaven? College bescherming persoonsgegevens? Dan moeten die ook de menskracht hiervoor krijgen.

Ook voor zwakke wachtwoorden is er al lang tooling bedacht in de vorm van techniek. (minimale wachtwoord lengte, regelmatig wisselen etc etc.)

[Romke]

Er kan sowieso wetgeving komen om bedrijven te verplichten de technische kant van dit verhaal in orde te maken. Het is daarna aan de organisatie die de software gebruikt om hun informatiebeveiligingsbeleid op orde te brengen. Want het afdwingen van sterke wachtwoorden is een uitvoering van een wachtwoordbeleid, welke slechts door de organisatie vastgesteld kan worden.

Hier kun je natuurlijk eisen aan stellen vanuit de wet. Maar je kunt niet als softwaremaker zomaar je klanten een wachtwoordbeleid opleggen.

[T-men]

Waarom zou je als softwaremaker niet zomaar je klanten een wachtwoordbeleid op kunnen leggen ?

Technisch is het geen punt, en 'politiek'... wel, het is jouw naam die te grabbel gegooid wordt. Lijkt me een sterk punt !

[Wim-Bart]

Veel bedrijven hebben een certificering waarbij dat beleid al wordt bepaald. Verkeerd wachtwoord beleid wordt meestal bepaald door een manager ergens die het maar vervelend vindt of door personeelsleden die het vervelend vinden. Echter is goed wachtwoordbeleid een must. wat men ook zegt. Daarom is SSO ook een goede oplossing, dan kan je wachtwoorden en gebruikersnamen gewoon gelijk houden in diverse omgevingen waardoor de drempel lager is.

Helaas zijn veel SaaS oplossingen (waaronder dit product) niet in staat om te integreren met de bestaande eigen systemen waardoor er vaak ingeboed wordt op security eisen en wensen om het voor de gebruiker "makkelijk" te houden.

Daarnaast ben ik nog steeds verbaasd dat dit product nooit met whitelists gewerkt heeft met ip-reeksen waarvan klanten toegang hebben in combinatie met encryptie. Dit geeft aan dat veel SaaS oplossingen dan ook nog te onvolwassen zijn om als veilig product binnen een organisatie te implementeren.

[Distrax1988]

Kan er niet wakker om liggen dat mensen weten dat ik een been heb gebroken, gebeten ben door een teek, en elke week bij de huisarts moet komen....

Zouden meer mensen moeten doen, eigelijk niet doen.

[D-Day]

Maar als je geen hypotheek krijgt omdat je depressies hebt met suicidale neigingen en er recent bij jou een gemetastaseerd prostaatcarcinoom is vastgesteld met een overlevingsprognose van <5 jaar?

[[Yellow]]

Totdat blijkt dat je 300% meer premie mag betalen omdat je vroeger als kind veel snoepte en nu meer kans maakt op een kunstgebit. Of iets dergelijks.

[robinverl]

Wat een trieste bedoeling zeg, je zou toch onderhand na een klein jaar media aandacht wel verwachten dat bedrijven met dergelijke informatie / risico's de eigen applicaties hebben doorlopen en gewijzigd zodat ze deze simpele aanvallen kunnen weerstaan.

Ik hoop echt dat er boetes komen voor dit soort gevallen.

[tweakmiv]

Volgens het artikel is een geslaagde aanval al uitgevoerd dus VCD moet zich schamen.

[The Reeferman]

Op naar de volgende.
Misschien toch eens tijd om een veiligheidstest verplicht te stellen voor dit soort databases.

[Juwayri]

En het leuke is, ik krijg de volgende advertentie:

Bang voor de cloud? Nergens voor nodig!
Onder ondernemers heerst vaak nog het misverstand dat werken in de cloud onveilig zou zijn. Maar niets is minder waar. Werken mét de cloud kan zelfs veel veiliger zijn dan werken zonder. Waarom angst voor de cloud onnodig is? Lees het hier.

Bewijst toch maar weer dat die achterdocht van sommige ondernemers niet geheel onterecht is. Begrijp me niet vekeerd, ik ben een voorstander van cloud computing, echter alleen als dit veiliger is dan insourcing.

[GreatDictator]

Tsja, veel data die in een cloud komt zal nu waarschijnlijk ook al ergens aan het internet hangen, dus wat dat betreft weet ik niet of dat nou zo veel verschil maakt.

[anboni]

Verschil is natuurlijk wel dat die cloud vaak toegang geeft tot data van een heleboel verschillende personen of bedrijven tegelijk. Een enkel lek heeft dan een veel grotere impact dan als datzelfde lek zou optreden bij een bedrijf dat alleen zijn eigen gegevens opslaat (en omdat er zoveel meer gegevens te vinden zijn, is het ook mogelijk een interessanter doelwit wat de kans op een aanval vergroot).

[GreatDictator]

Aan de andere kant zou je ook verwachten dat een grotere cloud dan ook beter beveiligd is, maar dat blijkt nu ook weer tegen te vallen