Minister De Jonge: ontwikkelaar wist niet van lek Infectieradar

Minister Hugo de Jonge spreekt nu toch tegen dat de ontwikkelaar achter de Infectieradar wist van het datalek waarbij coronasymptomen van anderen waren in te zien. Het blijkt nu dat het RIVM het datalek niet had opgemerkt omdat een beveiligingscheck niet is uitgevoerd.

De minister beantwoordde Kamervragen over de kwestie die vorige maand aan het licht kwam. Toen bleek na onderzoek van de NOS dat het eenvoudig mogelijk was om de coronasymptomen van anderen in te zien door de url aan te passen. Het systeem werkt met een uniek id dat uit acht cijfers bestaat.

Nadat het lek werd ontdekt, werd de website van de Infectieradar offline gehaald om aan een oplossing te werken. Minister De Jonge zei toen dat het probleem door het RIVM in de testfase al was opgemerkt en was doorgegeven aan ontwikkelaar Formdesk. Laatstgenoemde sprak dat echter tegen en reageerde verbaasd op de uitspraken. Uit het antwoord op de Kamervragen blijkt nu dat De Jonge zaken door elkaar heeft gehaald.

Het RIVM heeft namelijk weliswaar een aantal veiligheidsproblemen gemeld bij Formdesk waarna oplossingen zijn geadviseerd en geïmplementeerd, maar deze voorkwamen niet het probleem met het aanpassen van de url's. Volgens De Jonge had na het implementeren van de door Formdesk aanbevolen reparaties nog een extra check gedaan moeten worden door het RIVM om het probleem aan het licht te brengen, maar dit is niet gedaan.

Infectieradar is nog altijd offline, al is het wel mogelijk om je aan te melden. Het RIVM is bezig extra beveiligingschecks uit te voeren, waarna Infectieradar weer online komt. Wanneer dit is, is echter nog niet duidelijk.

Reacties (129)

[epoman]

Ook na meerdere decennia ervaring met software en internet (b)lijkt het voor veel partijen moeilijk om 'uitvoerig testen' een integraal onderdeel van het ontwikkelproces te maken, en niet een kostenpost achteraf om goedkoper/sneller te leveren. 'Niet af' is jouw probleem, maak dat niet het probleem van je klant of gebruikers.

Edit:
Je hebt in mijn optiek als ontwikkelende partij ook gewoon een verantwoordelijkheid om dit soort dingen goed te verkopen maar je klanten, en je rug recht te houden als je (met nieuwe inzichten) fouten of onrealistische afspraken blijkt te hebben gemaakt.

Ik was niet betrokken bij dit project maar de genoemde fouten en de manier waarop processen worden omschreven zijn tranentrekkend.

[Reactie gewijzigd door epoman op 23 juli 2024 17:01]

[Zoijar]

Dit zou je nooit vinden met testen, want dan moet je dus een test maken die dit geval checkt, en als je aan die test denkt, dan zal je het systeem nooit zo bouwen.

Dus testen is een beetje vreemd woord hier. Goed design bedoelt men. Want of ze het nou wisten of niet, dit was natuurlijk gewoon incompetentie en prutswerk. Nooit meer inhuren voor iets belangrijks.

[thewizard2006]

Lol. Als iemand die in het testvak zit kan ik je meegeven dat het aanpassen van een url toch een redelijk bekend testrisico is dat afgedekt dient te worden
En daarnaast maak je nog een denkfout dat testers geen fouten in het systeem kunnen vinden want dan had het wel beter designed. Waar denk je dat testers voor zijn. Juist om dat soort missers er uit te halen.
Dus in dit geval is er gewoon niet goed getest op dit punt. (en daarvoor niet goed gebouwd, en daarvoor niet goed designed).

[Reactie gewijzigd door thewizard2006 op 23 juli 2024 17:01]

[Mellow Jack]

En toch maken jullie beide de fout door te beginnen met het ontwikkeltraject en dan pas te starten met testen

Naar mijn mening hoort het design getest te worden zeker in agile achtige trajecten waarbij je kleine stukjes functionaliteit op levert en je het risico hebt het grotere geheel niet te overzien.

[PdeBie]

Test Driven Development biedt inderdaad zeker meerwaarde, maar kan ervoor zorgen dat de doorlooptijd enorm oploopt. En dat is wat men (vaak) niet wil.

[TabCam]

Of andersom. Het scheelt tijd omdat je fouten eerder vind en blijvend kan garanderen dat oude fouten niet opnieuw in het programma opduiken.

Het is voor de meeste niet-ontwikkelaars moeilijk voor te stellen dat het dan sneller kan gaan. Je ziet echter in de eerste maanden minder functionaliteit opgeleverd, maar alles is getest. In het niet TDD scenario wordt er echter verkeerde of onbereikbare functionaliteit opgeleverd. Die is dan van 0 waarde.

[PdeBie]

Je ziet echter in de eerste maanden minder functionaliteit opgeleverd, maar alles is getest.

En dat is dus precies een van de zaken die je moet overwegen. Gezien de haast bij de infectieradar hebben ze dus gekozen om snel functionaliteit op te leveren.

Het ontdekte lek is overigens zo'n basale fout, dat had nooit live mogen gaan natuurlijk. Ongeacht of het TDD of iets anders is.

[Wolfos]

Met test driven development vind je dit soort fouten niet. Dat beschermt alleen tegen wijzigingen, niet tegen denkfouten.

[Reactie gewijzigd door Wolfos op 23 juli 2024 17:01]

[PdeBie]

Correct. Ik heb ook nooit gezegd dat TDD de oplossing voor deze fout is. Het was een reactie op @Mellow Jack zijn verhaal dat je testen voorop moet stellen.

[thewizard2006]

Het is dat er een bij staat

Met jou redenatie zou je dus nooit een fout in productie kunnen vinden want alles is dan altijd al gevonden in het ontwikkeltaject. Zou natuulijk super fijn zijn als dat kon maar is helaas een utopia.

En ook in een Agile omgeving gaat de vlieger niet op dat "omdat er Agile ontwikkeld wordt" er geen fouten optreden. Fouten kunnen gemaakt worden in elke laag.

Waar ik op reageerde was dat "Dit zou je nooit vinden met testen, want dan moet je dus een test maken die dit geval checkt, en als je aan die test denkt, dan zal je het systeem nooit zo bouwen."
En dat is gewoon niet waar. Het is een prima te vinden fout in de programmatuur.
Dat je dit er eigenlijk al veel eerder uit had willen halen staat niet ter discussie.

[SuperDre]

tja, in de ideale situatie klopt het wat je zegt. Helaas is de praktijk anders, goede intenties, beginnen met tests schrijven etc, maar door druk worden sommige tests ineens pas achteraf geschreven en uiteindelijk maar helemaal weggelaten omdat het voor sommige developers teveel tijd kost om goede tests te schrijven waardoor de software ansich niet op tijd af komt en de baas dus toch wil dat de software op tijd geleverd wordt.

[Gwaihir]

Ik denk dat mensen die daarvan weten ervoor zijn om de anderen in hun project daarin wijzer te maken. Ja, een redelijke tester weet dat en test dat (achteraf). Maar een m.i. goede tester vraagt al vóór de bouw of hieraan gedacht is - en krijgt daar van z'n omgeving de ruimte toe. En (@Zoijar) daar kun je ook prima (conform (A)TDD) een automatische test voor maken:

Gegeven ik ben ingelogd als user A
Wanneer ik aanmelding X bekijk van user B
Dan zou ik een foutmelding moeten krijgen

En gezien hoe basic en essentieel dit stukje beveiliging is, lijkt me dat ook vrijwel altijd waardevol.

[Zoijar]

Ja, mijn opmerking ging meer over directe software tests, test driven development, unit testing, aangezien epoman het had over niet achteraf testen. Daarna, als je nog (externe) pen tests en integratie tests user acceptance etc uitvoert kan je het natuurlijk wel vinden, maar dan ben je de developer an sich al iets voorbij.

[epoman]

Met 'niet achteraf' bedoel ik 'voordat het live staat'.

[D11]

En het ontwerp ook niet getest.

[SuperDre]

Ach dat laatste gebeurd zo vaak, want om het ontwerp te testen moet men wel fatsoenlijke kennis hebben van het domein om te weten of het ontwerp zelf wel correct is.

[sympa]

Klopt, externe securitytesters nemen dit soort dingen standaard mee. Voor de hand liggende fout, en ook genoeg manieren waarop zulke fouten kunnen insluipen.
Toch blijft het dat je kwaliteit nooit ergens 'in kan testen'. Voor kwaliteit moet je architectuur goed zijn. Heb je meteen als voordeel dat je security niet broos is, maar dat er grote veranderingen nodig zijn om het te verpesten.

[Xerpan]

Helemaal met je eens.
In een ver verleden ben ik tester en testcoördinator geweest en weet hoe ontwikkelaars de 'schuld' bij de testende partij proberen te leggen. In dit geval het RIVM.
Als een product, of een deel ervan niet deugt, ligt dat niet aan de tester. Als het niet gevonden wordt, ligt het 'niet vinden' aan de tester, maar het niet deugen is nog steeds de verantwoordelijkheid van de ontwikkelaar.
Ik vind het schrijnend dat 20 jaar nadat ik uit het test-vak ben er nog steeds niets is veranderd aan de aanpak van ontwikkelaars. Ze bouwen en de testers moeten de mankementen er maar uit halen, terwijl die niets kunnen veranderen, alleen aangeven wat er anders moet/had gemoeten. Het probleem zit meestal al bij de ontwerpers. Maar die waren en zijn blijkbaar nog steeds heiligen.

Tot alle ontwerpers en ontwikkelaars zou ik voor de zoveelste maal willen zeggen: "de klant is niet verantwoordelijk voor (de kwaliteit van) jouw product. Dat ben je zelf".
Het is toch van de zotte dat de klant de kwaliteitscontrole moet doen.
Stel je eens voor dat het procukt een auto is en dat de klant de crashtest moet doen. Onacceptabel.
In de IT heel gewoon. Nog steeds.

[djwice]

LOL dit zijn zeg maar de eerste dingen die ik check; kan ik parameters in de URL veranderen (of in verborgen velden in het formulier) en wat krijg ik dan.

Daarnaast check ik altijd https://observatory.mozilla.org/ en dat moet B+ of hoger zijn. En als er gevoelige data wordt verwerkt A+ op alle fronten met 135 punten.

Simpele check die geautomatiseerd uitgevoerd kan worden.

Injecties van waarden vaak met 11 proef getallen lijkt me een heel normale test.
Er zijn ook open source lijsten met parameter attacks (OWASP regelateerd). Wij draaien die elke deployment en bij elke update van de lijst op al onze api's op alle parameters.

Lijkt me niet meer dan normaal. Je scant toch ook continu voor CVE's en library updates?

In dit geval blijkt ook dat de gevoelige data niet een encryptie key heeft per individu. Hierdoor leidt deze fout in de API tot ongeautoriseerde toegang. Als de toegang en login gekoppeld zou zijn aan de data via unieke encryptie sleutels had de data niet ontsleutelt kunnen worden.

Wij hebben dit sinds 2016 in het ontwerp en sinds 2018 in productie dankzij een grote cloud provider die deze techniek op mijn verzoek heeft ingebouwd in hun NoSQL database. Hierdoor is deze techniek zonder extra kosten voor iedereen beschikbaar is.

[Reactie gewijzigd door djwice op 23 juli 2024 17:01]

[SuperDre]

tja, voor jou is dit allemaal bekend omdat je er dagelijks mee werkt, maar ook jij wist dit ooit niet allemaal. Zelf heb ik bv nog nooit van die observatory.mozilla.org gehoord, maargoed ik ben ook geen webapplicatie developer (nog steeds geen tijd voor gehad om daar in te verdiepen, maar moet hoog nodig).

[djwice]

Mee eens, daarom kom ik eind van het jaar met een oplossing voor bestaande sites

Een proxy die dit real-time fixt, direct je site sneller maakt, beter laat werken op mobieltjes & beter vindbaar maakt in Google.

En als kers op de taart: je servers krijgen het rustiger


Maar goed dat URL checken deed ik ook al een jaar of 25 geleden, ook toen had niet elke partij dit goed op orde.

Eigenlijk moet er op projecten waar gevoelige data wordt verwerkt minimaal 1 persoon per team hier https://www.certifiedsecure.com/training de maximale certificeringen hebben gehaald.
(nota bene een Nederlandse partij)

[Reactie gewijzigd door djwice op 23 juli 2024 17:01]

[SuperDre]

tja, wij van wc-eend denk ik dan altijd bij dit door trainingen...

[djwice]

Ga hem eens doen, de online certificeringen hebben gratis online training en een actief forum voor tips.

En ik vind de kwaliteit erg goed.
Het leert mensen veel aspecten waar vele nooit eerder aan dachten. Het leert je als het waren denken als een hacker, om zo onafhankelijk van welke techniek je later gebruikt voor implementaties van applicaties, je er van doordrongen bent waar er gaten kunnen zitten. En waar je op moet letten bij het dichten.

[The Zep Man]

Dit zou je nooit vinden met testen, want dan moet je dus een test maken die dit geval checkt, en als je aan die test denkt, dan zal je het systeem nooit zo bouwen.

Een half competente penetratietest had hier gehakt van gemaakt en het gewoon gevonden.

Verder zou elke ontwikkelaar die fouten maakt zoals genoemd in de OWASP top 10 op staande voet ontslagen moeten worden. Daarmee is bewezen dat de ontwikkelaar niet veilig met industrieel gereedschap om kan gaan, en een gevaar is voor zichzelf en voor anderen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:01]

[tweakerbee]

Verder zou elke ontwikkelaar die fouten maakt zoals genoemd in de op staande voet ontslagen moeten worden.

Ik hoop dat je het bedrijf bedoelt, en niet individuele ontwikkelaars. Vrijwel iedereen maakt af en toe fouten. Met reviews en pentesten haal je die eruit. Dan moet je iemand juist bewust maken van de fout zodat ervan geleerd wordt.

[fastedje]

Inderdaad, fouten maken is menselijk. Als je iedere ontwikkelaar die een fout maakt moet ontslaan dan blijven er heel weinig tot geen ontwikkelaars over. Waar het vaak aan ontbreekt is een goed test en review process. Te complexe en niet te begrijpen code ook een groot risico.

[Verwijderd]

Ik ben het in dit geval met @The Zep Man eens. Dit zijn geen fouten. Dit is er niet mee bezig zijn. Puur amateurisme.

[ari3]

Tja, eigenlijk moet software ontwikkelaar een beschermd beroep worden net zoals arts of advocaat.

Programmeurs kunnen alleen hun vak uitoefenen als ze een relevante vakopleiding hebben gehad en training in het veilig programmeren. Daar hoort ook bij dat ontwikkelaars, net als artsen en advocaten, aansprakelijk zullen zijn voor de kwaliteit (waaronder veiligheid) van het werk dat ze leveren. Dit heeft als voordeel dat afnemers van software niet meer de partij zijn die bepaalt welke veiligheidsvoorzieningen aangebracht worden aan een applicatie. De programmeur is aansprakelijk dus wordt volgens de normen van de beroepsgroep software gebouwd.

[Cerebrus]

Hier ben ik het persoonlijk zeer mee eens. Vrijwel alles in onze maatschappij draait nu al op software, en als je ziet hoeveel amateuristisch werk ertussen zit dan lijkt het haast een kwestie van tijd tot de eerste grote ramp ontstaat door een grove fout van een programmeur, met alle gevolgen van dien.

software ontwikkelaar tot een beschermd beroep maken lijkt mij ook de enige manier om zo'n scenario te voorkomen en een kwaliteitsstandaard te waarborgen. Daar zou dan ook een beroepsraad bij moeten horen die een programmeur uit zijn functie kan ontheffen wanneer diegene grove fouten begaan heeft of zich niet aan de statuten van de beroepsgroep gehouden heeft of zich met onethische doeleinden bezighoudt.

[joelharkes]

Zeker, maar om nou iedereen te ontslaan die een hamer op de grond laat vallen is wel rigoureus.

Zeker voor overheids applicaties zou je toch denken dat inderdaad penetratie tests verplicht zijn. Kijk naar corporates die zijn zo 'bang'/voorzichtig, dat ze zelfs elke Saas applicatie die ze gebruiken zelf willen pen testen.

[The Zep Man]

Zeker, maar om nou iedereen te ontslaan die een hamer op de grond laat vallen is wel rigoureus.

Dit is geen hamer op de grond laten vallen. Dit is iets half vastspijkeren.

Zeker voor overheids applicaties zou je toch denken dat inderdaad penetratie tests verplicht zijn.

Penetratietests zijn niet bedoeld om het laaghangend fruit eruit te pikken. Opleiden en opvoeden van ontwikkelaars is goedkoper en effectiever. Pentesters kunnen zich dan concentreren op de fouten die niet makkelijk zijn te voorkomen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:01]

[THA_ErAsEr]

Verder zou elke ontwikkelaar die fouten maakt zoals genoemd in de OWASP top 10 op staande voet ontslagen moeten worden.

Over overdrijven gesproken...

De meeste punten op die lijst moeten tijdens het designen en analyseren al opgepikt worden. Als een ontwikkelaar er dan niet aandenkt omdat dat niet in zijn analyse staat, moet niet met de doodstraf beantwoord worden.

[SuperDre]

Grappig, had nog nooit van die top 10 gehoord. Dat jij misschien dagelijk daar mee bezig bent wil nog niet zeggen dat anderen dat dan ook allemaal weten, sommige mensen hebben bv hele ander expertises en hebben bv nooit aan de frontend of een echte webservice uberhaupt gewerkt, als je dan ineens aan een bepaald project moet werken dan zul je dus wel wat inlezen en beginnen. Maar als je nooit op dat soort problemen gewezen bent of tegen aan gelopen bent, dan kan ik me zeker indenken dat het helemaal niet zo voor de hand ligt.
Vergeet niet dat er zoveel terreinen zijn wat betreft software ontwikkelaars, webapplicaties is daar 1 van met zn eigen problemen, en als jij dus altijd webapplicaties hebt ontwikkeld dan zul je de meeste problemen wel weten, maar een kernel developer loopt weer tegen hele andere beveiligings problemen aan waar je als webapplicatie developer nog nooit van gehoord hebt of tegen aan gelopen bent, en het zal dus dan ook even duren voordat jij al die beveiligingsproblemen weet.

Het is makkelijk om een lijstje samen te stellen obv wat sommige mensen vinden wat anderen zouden moeten weten, maar daarmee maakt het nog niet een officiele lijst die iedereen kent.

[Gamebuster]

9 van de 10 ontwikkelaars die ik tegen kom kent die OWASP niet eens, laat staan de inhoud ervan

[Pathogen]

Check

[Gamebuster]

Ik zeg ook niet dat het acceptabel is, ik deel een ervaring

[sympa]

Tja, een tijd geleden gebruikte ik een contactformulier op een website van een groot bedrijf.
Ik kreeg een SQL error terug. Ik was namelijk zo stom geweest een puntkomma in mijn vraag te verwerken...

[gjmi]

Dus als je een goed design hebt hoef je niet te testen? Dat is wat ik lees. En dat is zo fout.....

Ten eerste: je kunt nooit alle eventuele problemen zelf bedenken. Daarom heb je ook een tester. Die kan testen schrijven en/of ook kant en klare producten gebruiken die allerlei penetratie testen kunnen doen, en afhankelijk van je product huur je zelfs een paar hackers in om problemen te detecteren..

Ten tweede: Stel je maakt een perfect design. Maar wie zegt dat de implementatie aan het design voldoet? Software kan zeer complex zijn. Daarom worden er ook testen gedaan of de implementatie wel aan het design voldoet. En vergis je niet. Testen is een vak apart.

Mensen maken fouten. Is het niet in het design dan is het wel in de uitvoering, of ook bij testen.
Iedereen maakt fouten, daarom heb je testen. Een ontwikkelaar maakt zijn eigen low level testen en op hoger niveau worden ook door iemand anders testen geschreven, om te voorkomen dat de ontwikkelaar zijn eigen fouten meeneemt in de test.

[Reactie gewijzigd door gjmi op 23 juli 2024 17:01]

[cracking cloud]

Ik lees: een goed design voorkomt knullige fouten zoals die nu gemaakt zijn en testen is een extra beschermingslaag om verkeerde designs of verkeerde implementaties te ontdekken.

[gjmi]

Dat is dus ook onzin. Een goed design voorkomt geen knullige fouten. Na design komt implementatie en daar kunnen heel makkelijk knullige fouten optreden.
Een goed design verkleint de kans alleen maar.

[epoman]

Eens, design was al dubieus. Maar een beetje tester kijkt verder dan happy flows en normale use cases. En een beetje pielen met urls is dan echt niet raar, zeker niet in een tijd met zoveel aandacht voor privacy.

[SuperDre]

Alleen een hoop testers (die ik ken in iedergeval) kijken niet verder dan de happy flows en normale use cases.
En wat natuurlijk wel is, als je de hele dag met bescherming etc bezig bent, ja, dan weet je wel wat de culprits kunnen zijn, maar als je daar amper mee te maken hebt dan is het een ander verhaal. Ieder heeft zo zijn/haar expertises.

[StefanJanssen]

Met automatische testen zul je dit misschien niet vinden. Met handmatige test kan dat heel goed.
Elke goede tester weet dat dit dingen zijn waar ze op moeten letten. URL aanpassingen is ook een van de eerste dingen die ze testen na een normale flow.

[gday]

En daarom is het dus verstandig om iemand anders te laten testen, zodat zulke aannames niet gedaan worden en alles gewoon goed getest wordt.

Los daarvan is het natuurlijk bizar dat dit überhaupt bij het ontwerp niet afgedekt is.

[Reactie gewijzigd door gday op 23 juli 2024 17:01]

[Lapjespoes]

Dit is klikklare onzin, dat is simpelweg niet hoe testen werkt. Je test niet voor een specifieke situatie, je test voor de algemene werking van je programma's en ontdekt hierbij issues om te fixen. Je controleert NIET specifiek voor de issues waarvan je niet weet dat ze bestaan, want duh, dan had je ze al bij het productieprocess gefixed.

[Zoijar]

Dat is dus precies hoe test-driven development werkt

Mensen, ik had het in mijn opmerking over development tests die niet achteraf worden gedaan in reactie op epoman, en de observatie als je expliciet zelf voor iets test dat je dat dan al in je design fase opmerkt; ik ontwikkel ook al 25 jaar software en weet best redelijk hoe de dingen werken

[Mellow Jack]

Ligt eraan wie. Een ontwikkelaar? Misschien wel. Een test engineer? Mijn ideale tester is iemand die het kapot kan maken

Bij externe projecten gaat mijn voorkeur daarnaast ook altijd naar een externe test partij die hierin is gespecialiseerd

Is ook nog eens afhankelijk van je type project, heb wel eens een project gedaan waar we een spin in een web moesten ontwikkelen wat kon integreren met 300+ interne systemen. Alles volgde standaard protocollen dus was het juist zaak om continue creatief te bedenken hoe iemand iets kon verzieken

[Rob Coops]

Wat ik me dan af vraag waarom bestaat dat endpoint?
Ik bedoel de app zal deze informatie nooit mogen tonen want privacy en anoniem dus zelfs als de app het zou tonen dan zou het nutteloos zijn omdat niemand weet welke van de personen om hen heen dit overgaat.

Wat ik me echt heel erg af vraag is of dit weer eens een verhaal is van scope creep. Was de app eerst bedoeld om mensen te waarschuwen dat ze misschien wel besmet zouden kunnen zijn want te dichtbij een ziek persoon die zich niet aan de regels van zelf isolatie hield (oppakken en opsluiten denk ik dan). Lijkt het er nu op dat het ook gebruikt kan worden door/voor de overheid om in de gaten te houden wie er welke symptomen heeft en wie weet wat men nog meer van plan is met deze overheids spyware.
Nu was ik altijd al tegen het idee dat de overheid een tracking app zou bouwen om de interactie tussen mensen in de gaten te houden en zo nog beter te weten wie waar en met wie in contact komt maar met dit soort incompetentie bij de ontwikkelaar en schijnbare scope creep van uit de opdrachtgever weet ik zeker dat ik helemaal nooit deze rommel op welke device dan ook zal zetten.

[sylvester79]

De infectieradar heeft niets te maken met de Corona App waar je naar verwijst.

[WittiW]

Testen start je direct met het ruwe plan. Testen is een integraal onderdeel van ontwikkelen. "Goed design" zou dus al getest moeten worden bij de vraag wat goed design dan inhoudt en vervolgens objectief te bepalen of je aan die doelstelling voldoet.

Hoe eerder je test, hoe minder foutoplossing kost.

[rko4u]

Er is een gespecialiseerd bedrijf ingezet volgens eerdere berichtgeving, en het probleem stond op de lijst. Het is alleen niet opgelost en niet hertest. Dat is van beide zijden verwijtbaar.

[rjberg]

Met een persoon misschien, maar als met meerdere personen dingen gebouwd of getest worden kunnen dingen door elkaar gaan, zeker in haast.

Hoewel ik me afvraag waarom deze specifieke fout telkens door de overheid wordt gemaakt met de URL. Een troonrede is hierdoor eerder uitgelekt.

[Verwijderd]

Je hebt ook nog zoiets als testers. Daarnaast zijn er legio tools die dergelijke 'fuzzing' op urls doen. Dit had echt al bekend moeten zijn.

[supersnathan94]

en als je aan die test denkt, dan zal je het systeem nooit zo bouwen.

Dit systeem had sowieso nooi op deze manier gebouwd mogen worden. 8 karakters als uniek ID is nooit voldoende. Daar ben je zo doorheen.

Waarom niet gewoon een UUID? Daar zijn die dingen voor. Dit is een beetje als MD5 gebruiken voor een password. Kan gewoon niet.

Security moet dan ook bij design al meegenomen worden. Als je uit je hoofd twee valide ID’s kan opnoemen mag je dat nooit gebruiken voor niet publieke data. Beetje URI/URL strategie houd hier dan ook rekening mee.

[Fladder80]

Mwoah, hangt toch ook een beetje van de afspraken af. Zou bij dit soort systemen eigenlijk verwachten dat het RIVM ook nog iets van acceptatie doet waar zoiets als dit gevonden zou moeten worden.

[DaMightyWackO]

Het RIVM heeft voor langere periode een zeer grote werkdruk. Ja ze zijn voorbereid op een crisis, maar dit vraagt veel van de organisatie. Daarbij komt; ICT is niet hun vak gebied en maken voornamelijk gebruik van SSC's. En ze hebben al grote ICT druk door dashboard, cijfer publicatie, omschakelen naar thuis werken. Daarom ligt ontwikkeling ook bij VWS (en ook dat is voornamelijk een regie functie). Kennis en capaciteit op ICT vlak is dus bijzonder schaars, acceptatie (goed doorlichten) leunen ze dus ook voor op externen (geen excuses, slechts een verklaring)

[Fladder80]

In mijn ervaring wordt daar in zo'n geval dan een andere partij voor ingehuurd die de acceptatie doet

[raptorix]

Bij professionele organisaties heb je vrijwel altijd met een PEN test te maken waaruit een rapport komt, zo een rapport bevat meestal voor 95% false positives of zaken met de indicatie: laag.
Met je team kijk je uiteraard eerst naar de Criticals en High, die wil je in ieder geval geëlimineerd hebben.
Voort komen er soms nog mediums uit, dat kan bijvoorbeeld een bepaald item zijn welk ansich correct gevonden is, maar omdat als het bijvoorbeeld geen publieke applicatie is, je dit als acceptabel ziet.

Vervolgens overleg je dit met de klant, en je vraagt daarop een akkoord, lang niet alle klanten zijn technisch genoeg om hier tot in details mee te kunnen praten, maar daarom is het van belang dat jij als ontwikkelde partij een duidelijk beeld weet te vormen.

Overigens is het tegenwoordig best practice om je security scans al in je pipelines op te nemen. Je kunt het zelfs zo inrichten dat als de scan slechte resultaten oplevert je je software niet door kunt voeren naar productie.

Maar nog even over dit specifieke probleem, dit is gewoon amateurisme van de bovenste plank, deze fout zag je in het verleden nog wel eens gemaakt worden door studenten die hun eerst formuliertje moesten maken, maar van iemand die dit voor zijn werk doet is dit onaanvaardbaar.

[Aiii]

In dit geval is het volgens mij gewoon een kwestie van teveel haast maken geweest. Ze hadden geen Covid-testcapaciteit en op dat moment stond de hele tent nog in de fik. Dus moet die app er ASAP komen.

Dan begint je opdrachtgever te pushen en geef je aan dat je best snel iets kunt maken en opleveren, maar dat dat verreweg van ideaal is en er meer tijd nodig is om iets gedegens te maken. Dus opper je een tweede fase om dat te doen, waarvan de opdrachtgever mondeling toezegt dat te doen. Dus hoppa, half product gaat online en het werkt allemaal, en vervolgens heeft de opdrachtgever ineens zo'n haast niet meer met die tweede fase en de tijd en kosten die daarmee gepaard gaan. En dan gaat het uiteindelijk voorspelbaar mis en dan ben jij als dev ineens de Sjaak, omdat het management geen oog en respect heeft voor wat er komt kijken bij dev werk, want het werkt toch?

Zoiets, zeg maar, lijkt mij nu niet geheel onwaarschijnlijk.

[epoman]

En die aanpak is de reden dat de afgelopen jaren tientalen tot honderden miljoenen aan belastinggeld is weggegooid met falende IT-projecten bij de overheid. We leren er niets van, dat was mijn punt.

[Pathogen]

Bij het bedrijfsleven gebeurt dit net zo veel overigens. Ik heb behoorlijk wat mislukte projecten voorbij zien komen die een stuk beter hadden kunnen lopen (of eerder afgeblazen) wanneer ook naar de negatieve geluiden geluisterd was.

[svenslootweg]

Infectieradar dateert toch al van voor Covid?

[Oon]

Dit heeft niks met testen te maken. Dit is gewoon een beginnersfout, die misschien een stagiaire in zijn/haar eerste jaar op een opleiding softwareontwikkeling zou maken.
Het is absoluut belachelijk dat de overheid in zee gaat met partijen die zo'n laag niveau produceren, en daar dan miljoenen voor rekenen.

[epoman]

Niemand levert na dat eerste jaar ineens uitsluitend foutloos werk af. En ook niet na tien of twintig jaar. De reden waarom het misgaat is minder belangrijk dan je vermogen zoiets op tijd door te hebben en te fixen voor iemand er last van heeft. Dus test je dingen.

[Oon]

Ik zeg niet dat je niet moet testen, absoluut niet, maar de fout waar het hier om gaat is een ontwerpfout die gewoon niemand die geld verdient met het ontwikkelen van websites zou moeten maken. Zelfs iemand die net afgestudeerd is en voor het eerst een echte baan als developer heeft zou al niet meer zo'n fout moeten maken, want één van de criteria bij het ontwerpen van zo'n systeem is beperkte toegang tot gegevens. Deze fout was op het niveau van wachtwoorden opslaan in plaintext of een centrale caching gebruiken voor pagina's gegenereerd voor ingelogde gebruikers (met als resultaat dat de pagina voor de eerste gebruiker die de cache vult getoond wordt aan iedereen). Daar is testen geen excuus voor.

Buiten dat testen inderdaad belangrijk is en een code audit of pentest dit zo tevoorschijn had getoverd, slaat het gewoon nergens op dat de overheid hier niks mee doet. Keer op keer hebben we IT-projecten die miljoenen kosten met hele slechte resultaten, alsof ze IT-partners kiezen op basis van persoonlijke relaties oid. Je zou enige kwaliteitseis verwachten van deze bedrijven, maar die is er gewoon niet.

[epoman]

Ja, eens. Was ook een beetje m'n oorspronkelijke punt, we/ze leren te weinig van het verleden en dat kost een hoop geld en ellende. Onbegrijpelijk.

[ramon.ackermann]

Niet alleen testen, maar bij een zo een opdracht, waar het om gevoelige gegevens gaat, laat je ook een penetratietest uitvoeren, uiterlijk dan had het gesignalisiert moeten worden.

Maar elke klein beetje ervaren developer weet dat je nooit oplopende id's van accounts of persoonlijke data gebruikt wanneer deze zichbaar zijn. Dit is gewoon een beginnersfout, en dan twijvel je ook weer aan de geschiktheid van een bedrijf, dat ongecontroleerd werk van een beginnende developer gebruikt, voor overheidsopsrachten dan ook nog...

[epoman]

Ja, precies.

[Verwijderd]

En bij een project wat zo onder de loep ligt moet je ook gewoon een pen-tester inschakelen. (Niet ter vervanging van je eigen test traject).

Edit: spuit elf.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 17:01]

[Hanzo]

Offtopic maar toch:
Ik hoop en mag, denk ik, toch wel verwachten dat het Corona vaccin dat hier nu ontwikkeld wordt stukken beter gescreend en getest wordt voordat ze het op de gewone mensen loslaten.....Onze "normale" medicijnen doen er gemiddeld een jaar of 10 over voordat er überhaupt toestemming gegeven wordt om de markt te betreden, dit om er zeker van te zijn dat alle bijwerkingen (en de risico's daar weer van) in kaart gebracht zijn. Haastige spoed, ................

[Reactie gewijzigd door Hanzo op 23 juli 2024 17:01]

[rvt1]

"Minister de Jonge: ontwikkelaar wist niet van lek Infectieradar

Dat is ook raar, want op 17 Maart 2020 heb ik de ontwikkelaar maar ook het rivm nog de volgende mail gestuurd:

subject: infectieradar.nl op Python + heel oude versie Django??
Hoi .......
Ik kreeg nu een ‘stacktace’ te zien van heb-ik-jouw-daar waar jouw naam instond, zo ook van .....…

Stond ook keurig in dat het op django 1.3.3 ging… dat ook een oudje.
Ik vondt het niet prettig om te weten dat een dergelijke site om sterk verouderde software draait, zeker in deze tijd lijkt het ons belangrijk dat deze snel en stabiel draait op moderne architecture.

Hey RIVM heeft mij ook keurig terug gemaild met een kenmerknummer

Wellicht heb ik niet direct gemeld dat er een lek zat maar dat leek mij nogal overbodig met dergelijk oude software. Dus niet geweten???

[Nas T]

Vervelend dat dit misverstand op dit niveau plaatsvindt, maar dat geeft (voor mij in ieder geval) maar weer meer reden om mijn gegevens zo min mogelijk bij de overheid achter te laten.
Er zijn twee redenen waarom ik dit zou doen:
1. (gebrek aan) competentie
2. Onjuiste intenties

Dit lek is één van de voorbeelden van hoe competent de overheid in het algemeen is met betrekking tot verwerking van onze gegevens. In dit geval zou een middelbare scholier handig genoeg zijn om gevoelige gegevens van anderen te kunnen achterhalen. Er zijn talloze voorbeelden van datalekken door de overheid, al dan niet ernstig in mate.

Intenties vind ik misschien nog wel belangrijker. Als je kijkt hoe SyRI onschuldige burgers heeft kunnen vlaggen als potentieel fraudeur en dat een rechter uiteindelijk moet beslissen om er mee te stoppen, vind ik een kwalijke zaak. Het is heel makkelijk om de overheid en ons als burgers te zien als een baas tegenover de gewone man, maar dat is kort door de bocht en hoe er nu omgegaan wordt met de maatregelen omtrent Corona, geeft dit goed weer: veelal worden er aanbevelingen gegeven en geen harde maatregelen. Het is niet de taak om de burgers zwart/wit te sturen, maar om ze te informeren: dit is beter van wel, dit is beter van niet en ons als burger zelf de verantwoordelijkheid te laten nemen.

Maar bij SyRI wordt ik wantrouwig: als een rechter de overheid moet gaan stoppen, omdat onschuldige burgers de dupe worden, dan zie ik dat niet als een overheid die de burger helpt. Maar dat moet het wel zijn. Wat ik nog belangrijker vind, vooral bij de discussie om de Corona-app, is het gebrek aan de benoeming van het nut er van.
Ik denk dat we als burgers héél scherp moeten zijn als het om onze gegevens gaat om ze af te staan als het nut onomstotelijk bewezen vast staat. Waarom moeten we onze gegevens af gaan staan, als ze ons niet helpen, maar ons wel kunnen bijten als individu (zie SyRI)?

Voor mij is de keuze nu heel duidelijk: ik ga nul gegevens vrijwillig afstaan aan een Corona app. Reden is simpel: er is onvoldoende nut. De maatregelen die nu worden getroffen, lijken mij afdoende en de toegevoegde waarde van een Corona-app kan in mijn ogen ook op een andere manier worden gerealiseerd.

De discussie gaat trouwens nog veel verder: wat we nu al jaren hebben toegelaten met big data door bedrijven, wordt nu dus gebruikt door overheden. Voor ons, maar ook tegen ons. Ik ben sterk tegen het gebruik van persoonlijke informatie om daar winst mee te kunnen maken. Winst is een prikkel om activiteiten die die winst genereren, uit te breiden. En nu zijn we in een situatie waarin big data zich goed heeft kunnen ontwikkelen, door onder andere de hulp van bedrijven, en nu door overheden gebruikt gaat worden, niet altijd in het voordeel van ons.

Gelukkig is er een beetje een besef hieromtrent bij grote bedrijven om overheden te helpen (in de vorms van cloud-diensten, of gezichtsherkenning). Maar we gaan nog een lange golf aan problemen krijgen wat betreft persoonlijke gegevens. Ik hoop alleen dat we hier op tijd achter komen en in kunnen grijpen.

[CurlyMo]

Dit lek is één van de voorbeelden van hoe competent de overheid in het algemeen is met betrekking tot verwerking van onze gegevens. In dit geval zou een middelbare scholier handig genoeg zijn om gevoelige gegevens van anderen te kunnen achterhalen. Er zijn talloze voorbeelden van datalekken door de overheid, al dan niet ernstig in mate.

Ik kan de cijfers niet voor je produceren, maar ik zou wel eens benieuwd zijn naar relatieve getal achter deze lekken. Hoeveel systemen zijn er bij de overheid actief die persoonsgegevens verwerken en met hoeveel zijn er (ernstige) problemen geweest. Ik denk namelijk dat dat enorm meevalt. Het is namelijk alleen nieuws wanneer het mis gaat.

Ik kan misschien onvoldoende op de hoogte zijn, maar ik heb nog nooit berichten gelezen over dit soort problemen als het gaat over de Basisregistratie Personen, Basisregistratie Kadaster, Reisdocumentenstelsel, Belastingdienst data, SVB data, AIVD, MIVD, CBS, enz.

Maar bij SyRI wordt ik wantrouwig: als een rechter de overheid moet gaan stoppen, omdat onschuldige burgers de dupe worden, dan zie ik dat niet als een overheid die de burger helpt. Maar dat moet het wel zijn. Wat ik nog belangrijker vind, vooral bij de discussie om de Corona-app, is het gebrek aan de benoeming van het nut er van.

Je hebt natuurlijk in de basis gelijk. Het is ook schandalig dat dit vanuit de overheid zo gebeurt. Vergeet echter niet dat het een politiek klimaat is waarbinnen dit soort beslissingen worden genomen. Hoe moeilijk is het voor de politiek om niet toe te geven aan dit soort tendensen vanwege het gevaar dat de kiezer naar populistische partijen overstapt, die sowieso al wat minder kritische staan tegenover de rechtstaat.

‘De mogelijkheden van gegevensuitwisseling moeten optimaal worden benut’, zei minister Lodewijk Asscher van Sociale Zaken en Werkgelegenheid. ‘Dit draagt bij aan het draagvlak in de sociale zekerheid en een adequate fraudebestrijding.’

Frans Weekers dreigde voor de Bulgarenfraude een motie van wantrouwen aan zijn broek te krijgen als hij niet zelf was opgestapt. Precies de casus die ten grondslag lag aan het beleid van de belastingdienst waar we nu zoveel over lezen.

Er was weinig ruimte voor kritische reflectie over de voor en nadelen van het betreffende beleid. Alles moe(s)t hard, harder, hardst. Je ziet het ook nog steeds in ons strafrecht. Straffen worden zwaarder en langer, TBS wordt vaker opgelegd, gratie minder makkelijk verleend. Ondanks alle onderzoeken die het tegendeel pleiten, dat langer en harder straffen niet werkt en de criminaliteit in Nederland al decennia een dalende trend laat zien. 'Voordeel' is alleen dat de populatie waar dit betrekking op heeft veel minder gevoelig is (veroordeelde criminelen*) dan bij SyRi (kansarme burger) en de belastingdienst (ouders met een dubbele nationaliteit). De essentie blijft hetzelfde.

De burger krijgt de overheid die hij verdient. De lagere tolerantie van de burger zie je terug in overheidsbeleid, waarbij wij gelukkig een onafhankelijke rechtstaat hebben die de overheid en daarmee burger zo nu en dan terugfluit.

ik ga nul gegevens vrijwillig afstaan aan een Corona app

Dit is tendentieus, omdat al is aangetoond door ook privacy waakhonden dat de nieuwe Corona app geen privacy gevoelige data verwerkt. Dat je ervoor kiest de Corona app niet te gebruiken staat je natuurlijk vrij.

En nu zijn we in een situatie waarin big data zich goed heeft kunnen ontwikkelen, door onder andere de hulp van bedrijven, en nu door overheden gebruikt gaat worden, niet altijd in het voordeel van ons.

Vergeet niet dat wij die overheid zijn. Opnieuw, de burger krijgt de overheid die het verdient. Wij stemmen, wij kiezen voor een beleidsrichting die door partijen wordt uitgestippeld. Die is de laatste tijd steeds minder tolerant. Het is nu al jaren lang voornamelijk het beleid van de VVD. Dan weet je ook dat een liberaal rechts beleid krijgt in Nederland. Als je het daar niet mee eens bent, dan heb je gelukkig de volgende verkiezingen of rechtelijke macht / toezichthouders om je bij te beklagen.

Zie ook de casus van de scholen sluiten om Corona. De wetenschap was vrij eenduidig. Het had geen zin. De maatschappij wilde echter iets anders. Leraren die werk zouden neerleggen, ouders die kinderen niet naar school lieten gaan. Onder maatschappelijke druk zijn de scholen gesloten.

De discussie gaat trouwens nog veel verder: wat we nu al jaren hebben toegelaten met big data door bedrijven, wordt nu dus gebruikt door overheden.

Je haalt nu doel en middel door elkaar. Ik zie het probleem niet van een overheid die nieuwe technieken toepast om beter beleid en uitvoering te realiseren. Integendeel. Mits dit met goede waarborgen gebeurt. Big Data als methode is niet het probleem. Dat is enkel een middel om een doel te bereiken. Het gaat mis bij oneigenlijk gebruik van de betreffende middelen. Daar moeten we inderdaad de overheid scherp op houden.

*Het gratie verzoek van Loi C. is nog altijd niet ingewilligd ondanks dat alle instanties anderszins adviseren

[Reactie gewijzigd door CurlyMo op 23 juli 2024 17:01]

[supersnathan94]

Je hebt helemaal gelijk. Het geschetste beeld is natuurlijk vrij eenzijdig, want je haalt alleen het nieuws met falen.

Ik heb echter wel een kanttekening:

Basisregistratie Kadaster

Naar aanleiding van de invoering AVG is hier best wat discussie over geweest. Het is namelijk by design mogelijk om dergelijke informatie gewoon te kopen. Dit is altijd zo geweest en is ook altijd de intentie geweest. Ook volgens de wet. In heel veel gevallen gaat het dan om notariële aktes. Dat is best wel gevoelige info om het zo te zeggen.

Het kadaster heeft dan weer het geluk dat de overige registraties die ze voeren veelal publiekelijke informatie betreft. Daar valt dus weinig in te lekken. Vwb de gevoelige info is er alleen ongeoorloofde toegang. Als in er is niet voor betaald.

Aan de andere kant zit het grote gevaar hem er in dat er ongeoorloofd data wordt toegevoegd die bijvoorbeeld niet klopt. Met ~300 gemeentes, 12 provincies, RWS en waterschappen is die kans groot. Security is daar dan ook behoorlijk belangrijk, maar dan voornamelijk aan de ETL kant. Niet zozeer publicatie.

[CEx]

Die rectificatie heeft wel lang op zich mogen wachten. Lullig voor Formdesk.

[CaptainCapslock]

Formdesk heeft schandalig slechte troep opgeleverd. Zelfs beginnende developers snappen dat als je hier geen check voor inbouwt al je data kan uitlekken.

[Falcon]

Formdesk is een framework/basis, de inrichting en configuratie werd gedaan door RIVM.

I stand corrected.

[Reactie gewijzigd door Falcon op 23 juli 2024 17:01]

[darthdrinker]

Dan nog zou dit niet mogelijk moeten zijn als je met ingelogde gebruikers werkt, dit is basis authorisation en authentication. Dit zit zelfs in de OWASP top 10 je mag je doodschamen dat je in 2020 sofware aanbied die dit mogelijk maakt.

[Jan-E]

Nee. Formdesk is in dit geval de leverancier uit Wassenaar. Lees ook https://www.computable.nl...ctieradar-na-datalek.html

[CEx]

Haha nee het is zeker amateuristisch, maar daar hebben we comments van volgeschreven. Dat vervolgens minister de Jonge het bedrijf voor de bus gooit met een leugen, wat het bedrijf terecht aanstipt in de media en daarna pas erkent dat het niet klopte na lange tijd en na Kamervragen over dit punt is wel triest. En dan is het excuus ook nog dat hij het verwart had.

[AibohphobiA BoB]

Dat is het hele probleem van Hippe Hugo. Hij probeert alles op te lossen door even snel wat software er tegenaan te gooien en hoopt dat het zijn problemen oplost.
De eerste stap, kijken of het wel een goede oplossing is, daar gaat het al mis. Een online poll is sowieso al twijfelachtig.
Maar als je de beveiligingscheck overslaat is dat gewoon een aftreden waard.

[Razwer]

Het grotere issue is dat security audits blijkbaar niet of niet goed gedaan worden.
In Canada doet bijvoorbeeld BlackBerry de security review terwijl de ontwikkeling door een andere partij is.
https://erticonetwork.com...covid-19-app-more-secure/

Eigen vlees keuren is meestal geen goed idee.

[NielsFL]

Wat dan weer wel slim van ze is geweest is om onder handelsnaam Formdesk te werken en niet de daadwerkelijke bedrijfsnaam Innovero Software Solutions B.V.

[space-one]

Ze wachten zolang omdat de Tweede Kamer met reces is tot 31 augustus en de verkiezingen van het CDA zijn geweest.

[Kecin]

Bijzonder. Elke ontwikkelaar weet toch gewoon dat dit niet handig is. Je ziet toch snel genoeg dat je incrementeel bezig bent; dat weet je al bij het ontwerpen. Je kan amper spreken van een lek en eerder een functie zo aanwezig en duidelijk dit was.

[Crotchy]

Lijkt mij vooral dat dit gewoon prutswerk van een incompetente developer is.
Als het je niet invalt tijdens het ontwerp of ontwikkelen dan ben je wat mij betreft kompleet ongeschikt om op wat voor manier dan ook met persoonsgegevens te werken.

Van een lek of gemiste tests kan je echt niet spreken, tenzij het tests voor de kwalificaties van de developer zijn.

[cracking cloud]

Inderdaad, dit is een beginnersfout die tijdens een goede PR review eruit gefilterd had kunnen worden, en anders wel tijdens een degelijke test.

[SuperDre]

Achja, het is toch uiteindelijk de tester die verantwoordelijk is voor wat er naar productie gaat......

[Nas T]

Lek of geen lek, gevoelige gegevens zijn praktisch onbeschermd beschikbaar voor anderen en dat moet niet mogelijk zijn. Ik geloof wel dat een ontwikkelaar weet dat dit niet handig is, maar ik vraag me af of de ontwikkelaar(s) zich hiervan bewust was/waren.

[Geim]

Rivm is volgens mij een overheidsdienst, waarom dan geen gebruik maken van digid om je gegevens in te zien?

[Unsocial Pixel]

Neen, officieel is het rivm onafhankelijk. Echter zijn ze met de corona anders gaan handelen. (iets waarvan ze al aangegeven hebben dat ze hieraan gaan werken)

[CH4OS]

Zijn verzekeringen (zorg, pensioen e.d.) dat ook niet (onafhankelijk)? Toch dien je daar ook met DigiD in te loggen. Als het dan toch al breder gebruikt wordt om in te loggen dan aanvankelijk de bedoeling was, maakt 1 partij extra natuurlijk ook niet meer uit.

En kijkend naar de website, zijn ze "gewoon" onderdeel van het ministerie van Volksgezondheid, Welzijn en Sport.

[Reactie gewijzigd door CH4OS op 23 juli 2024 17:01]

[Lord Anubis]

Klopt, officieel onafhankelijk, en ze denken ook onafhankelijk, zelfs onafhankelijk van de realiteit.

[Earry]

Ze werken onafhankelijk maar vallen gewoon onder het MinVWS (ministerie van volksgezondheid, welzijn en sport). Niet eens een ZBO dus.

[jip_86]

https://nos.nl/nieuwsuur/...sis-te-veel-vermengd.html

Is niet onafhankelijk. Is aardig door elkaar gaan lopen. Maar zag je ook al bij de boerenprotesten. De RIVM directeur moest toen eerst even met het ministerie bellen of die nog een keer terug mocht om een hand te geven. Dit mocht toen niet, een onafhankelijke directeur zou dat zelf besluiten.

[GeforceAA]

Je moet toch per inlog betalen om gebruik te maken DigiD.

[gday]

DigiD is een product van de Rijksoverheid zelf dus er is vast wel een mouw aan te passen als er intern kosten doorbelast zouden worden voor gebruik.

[CH4OS]

Euh, oeps! Ik reageerde op de verkeerde!

[Reactie gewijzigd door CH4OS op 23 juli 2024 17:01]

[StefanJanssen]

Dan kun je beter riskeren dat je een onveilig systeem hebt en dat je hoge boetes moet gaan betalen.

(dit is sarcasme trouwens)

[Reactie gewijzigd door StefanJanssen op 23 juli 2024 17:01]

[field33P]

Volgens mij was het sowieso niet de bedoeling dat mensen na invullen hun eigen gegevens konden teruglezen. Verder zou een DigiD-gebaseerd systeem inhouse gerold moeten worden, terwijl er juist voor Formdesk gekozen werd om het snel te kunnen uitrollen.

[WhatsappHack]

Hoezo? Externe partijen kunnen ook de DigID-integratie regelen.

[hhoekstra]

Hou zou toch een anonieme dienst worden die niet terug is te lijden per persoon? Of loop ik alweer achter.

[PaulZ]

Ik ben in-house ontwikkelaar bij een overheidsdienst en dit is wel t eerste dat dichtgetimmerd wordt. Ik heb het artikel met verbazing gelezen en vraag me ten zeerste af of het in-house ontwikkelen i.p.v. geforceerd uitbesteden aan derde partijen niet veel goedkoper (en misschien wel beter) zou zijn. Moet je wel aan je kwaliteit van je ontwikkelteam werken, dat dan weer wel.
Want alles wordt uitgekleed en aan de marktwerking overgelaten. Daar maak ik me best wel zorgen over na alle fiasco's die ik voorbij zie komen.
'Professionals' op de markt hebben m.i. maar één doel: spullen verkopen en winst maken, i.p.v. dat er aan de burger wordt gedacht.

[epoman]

In-house heeft voor- en nadelen, net als extern. Lastige kwestie, veel factoren die meewegen. Hoeveel mensen heb je nodig, hoe lang, welk niveau, welke specialismen, tarieven vs loonkosten, hoe goed is de aansturing, heb je ruimte voor werkplekken (nu anders wellicht), heb je ooit nazorg/ondersteuning nodig en hoe lang dan, waar ligt intellectueel eigendom, ...

Soms kun je bepaalde punten prima vooraf bepalen of vastleggen maar de rest wordt vaak duidelijk met voortschrijdend inzicht.

[ocrammarco]

Altijd gevaarlijk om met namen in de media dit gevecht uit te vechten. Wat niet door VWS is aangeven is wat er gevraagd is en wat er betaald is. Zonder die info is het erg gevaarlijk om met de vinger naar de ontwikkelde partij te wijzen.

[Caelestis]

Dit is ook precies de reden dat Bits of Freedom geen onderdeel wou zijn van dit project. Ze zagen in het begin al dat het niks gaat worden m.b.t beveiliging en hebben dat ook duidelijk geuit.
Toch tegen beter weten in zetten ze vol door en nu dat het mis gaat is het eerste ronde van vinger wijzen gestart...

[M3m30]

Niet alleen dat... de controle was van te voren op alle wegen al erg slecht.
Er werd niet gedacht aan privacy bijvoorbeeld en met deze houding zullen nog minder mensen bijvoorbeeld die coronamelder app installeren en als naar buiten komst dat het RIVM foutief heeft gehandeld over gezichtsmaskers... tja...

[Verwijderd]

Dat zeggen programmeurs wel vaker, "U heeft niet aangegeven dat het veilig moest zijn"
Nee, dat is het werk van de programmeur, elk stukje software moet veilig zijn, tenzij is aangegeven dat het niet veilig moet zijn, bijv voor test/onderzoeks werk. Als ik naar een garage ga met mijn auto verwacht ik ook dat zij een veilige auto opleveren met de juiste banden, remmen etc etc. Daar zou je niet om hoeven te vragen.

[Unsocial Pixel]

Even vanuit mijn eigen ervaring als programmeur en ervaringen van bekenden die als aannemer of gelieerd aan een aannemer werken:
Wij zien welleens dingen waarvan wij denken; dit kan beter anders gedaan worden (en soms ook gewoon dingen van dit wil je niet), uiteindelijk is het de opdracht gever die beslist, wij kunnen het aangeven en een motivering erbij plaatsen. Bij het ene bedrijf word hier daadwerkelijk naar geluisterd, bij een ander heb je gelijk ruzie of word er je simpelweg verteld dat de klant dit niet wil. Uiteindelijk schrijf jij een product voor de klant, de klant bepaald de eisen en als de klant nee zegt is het nee. Als je een goede baas hebt en je hebt simpelweg een punt dan zal je baas met de klant in gesprek gaan echter doet ook niet elke baas dit en zit ook niet elke klant hierop te wachten. Ik heb nog nooit een programmeur horen zeggen wat jij hier schrijft,, persoonlijk zou ik zo een onverschillig persoon ook niet in mijn team willen. IT is meer dan enkel code kloppen, een heel groot gedeelte is communicatie, discussie en vragen vragen en nog meer vragen tot je een compleet plaatje hebt.

Sidenote, de fout die hier echter gemaakt is was wel echt super knullig en had nooit voor mogen komen. Iedere junior zou dit nog snappen lijkt mij

[Reactie gewijzigd door Unsocial Pixel op 23 juli 2024 17:01]

[vanstra]

Typisch politiek. Zelf de verantwoordelijkheid niet durfen nemen en deze verantwoordelijkheid bij een ander neerleggen. Eigen straatje schoonvegen.

[Chopp]

Dit had toch al in het ontwerp proces naar boven moeten komen. Een beveiligingscheck klinkt als een test die je pas na het ontwerpen en na en tijdens het ontwikkelen uitvoert.

[Tjm De Groot]

Ik was al niet van plan om die app te installeren en al zeker niet een app van de overheid, want
De overheid en ICT projecten zijn altijd al op een fiasco uitgedraaid wat miljoenen aan belastinggeld heeft gekost.

Kortom ze leren het nooit.