De Jonge: beveiligingslek Infectieradar was bij ontwikkelaar bekend
Het beveiligingslek in de Infectieradar van het RIVM waardoor het zeer eenvoudig was om medische gegevens van deelnemers te achterhalen was bij de ontwikkelaar bekend, zo heeft minister De Jonge vanmiddag tijdens het Vragenuur in de Tweede Kamer laten weten. Dit weekend bleek het door een kwetsbaarheid mogelijk te zijn om vragenformulieren te bekijken die door deelnemers waren ingevuld om aan Infectieradar deel te nemen.
Het RIVM liet gisteren weten dat er verschillende veiligheidschecks op de software van Infectieradar waren uitgevoerd, maar dat het beveiligingslek toch aanwezig was. Nu blijkt dat de ontwikkelaar wist van de kwetsbaarheid. "Bij het ontwikkelen van die site zijn er juist wel veiligheidschecks gedaan. Pentests, waarbij ook dit als één van de veiligheidsrisico's in beeld is gekomen. Vervolgens is daar een oplossing voor aangedragen die Formdesk moest doorvoeren", aldus minister De Jonge.
De minister liet weten dat het vragenformulier van Formdesk ook door andere websites wordt gebruikt. "Er is gevraagd aan Formdesk om een oplossing te verzinnen. Deels is dat overgenomen en deels niet. En vervolgens is er verzuimd om daarop een dubbelcheck uit te voeren. Er is gewoon vergeten een dubbelcheck uit te voeren daar waar die wel had moeten plaatsvinden. Kortom buitengewoon ongelukkig, maar er is wel gelijk geacteerd." De Jonge voegde toe dat het datalek ook buitengewoon ongelukkig is voor het vertrouwen van burgers in websites van de overheid.
Tevens stelde de minister dat alle getroffen deelnemers aan Infectieradar zondag via een persoonlijke e-mail zijn geïnformeerd. Niet getroffen deelnemers hebben gisteren een bericht ontvangen. Het datalek is gemeld bij zowel de Autoriteit Persoonsgegevens als het Nationaal Cyber Security Centrum (NCSC) van het ministerie van Veiligheid en Justitie, dat in contact staat met Formdesk. "Menselijke fouten zijn menselijk en waar mensen werken worden fouten gemaakt en hier is een fout gemaakt. Vervolgens gaat het ook om de manier waarop je het herstelt en ik vind dat het RIVM dat netjes doet", liet De Jonge weten.
Infectieradar
Het RIVM houdt op verschillende manieren de verspreiding van infectieziekten in de gaten, wat ook geldt voor het coronavirus. Hiervoor wordt onder andere de website Infectieradar gebruikt. Deelnemers kunnen één keer per week doorgeven of zij in de afgelopen week koorts of andere klachten hebben gehad. Bij het aanmelden voor Infectieradar moet een formulier met medische gegevens worden ingevoerd. Het gaat dan om het gebruik van medicijnen en waarvoor dit is, of deelnemers roken of allergieën hebben en of men zwanger is.
Deze invulde formulieren waren, door alleen het aanpassen van een getal in de adresbalk van de browser, voor derden toegankelijk, zo werd dit weekend duidelijk. Formdesk heeft inmiddels een oplossing ontwikkeld. Die wordt "zes keer" gedubbelcheckt, aldus de Jonge. Zodra blijkt dat de vragenlijsten veilig worden opgeslagen gaat het RIVM weer verder met Infectieradar. Het is al wel mogelijk voor mensen om zich aan te melden voor Infectieradar. Deze gegevens worden in een ander systeem opgeslagen.
Update
Formdesk laat in een reactie aan NU.nl weten dat het niet van de kwetsbaarheid afwist. Het beveiligingslek was niet eerder aan het licht gekomen en ook niet aan het bedrijf gemeld. "Ik heb werkelijk geen idee waar de minister het over heeft", zegt Marco Beuk van Formdesk.
in de ic thuis.
En dan nu weer het voorstel voor de Corona wet die 1 juli ingevoerd moet worden, vol met verboden die ondemocratisch voor onbepaalde tijd ingevoerd kunnen worden. Nederland begint aardig op de voormalige DDR te lijken...
Testen is bewijs vinden dat er fouten in zitten. Testen is niet bewijzen dat het foutvrij is.
> "Menselijke fouten zijn menselijk en waar mensen werken worden fouten gemaakt en hier is een fout gemaakt. Vervolgens gaat het ook om de manier waarop je het herstelt en ik vind dat het RIVM dat netjes doet", liet De Jonge weten.
Het is fout gegaan, tja kan gebeuren, wel netjes bezig vindt hij. Overheid kan met deze uitspraak niet serieus genomen worden wat de privacy betreft.
Wat een laf excuus. Mensen leren doorgaans. Dit soort fouten maakten we 20 jaar geleden ook al. Het was gewoon echt niet nodig.
dit is ongeveer de meest basale fout die je kan maken en als je als ontwikkelaar zoiets in je hoofd haalt heb je echt niets maar dan ook niets in de IT te zoeken.
Weet de minister wat een dubbelcheck betekent? Ik denk het niet. Er is volgens zijn informatie geen enkele check uitgevoerd op de vermeend gerepareerde software. Dat is falen in de controle. Er is geen excuus voor.
Overigens is een softwarefout van deze orde ruim voldoende reden om te stoppen met te leverancier. Als je zo blundert ben je niet in staat te leveren. Dat is als het in gebruik nemen van een 4e handsauto van occasioncentrum Beun de Haas waarbij je net ontdekt hebt dat de remkabels niet vastzitten en de wielbouten ontbreken. Als je dan niet denkt "wat zou er verder niet in orde zijn?" heb je het niet begrepen. En als je toch gaat rijden zonder te controleren of de remkabels en wielbouten er inmiddels wel goed op zitten, ben je nalatig.
Maar nu: oogjes dicht, en snaveltjes toe.
Slaap lekker!
https://www.nu.nl/tech/6056789/minister-legt-lek-infectieradar-bij-ontwikkelaar-bedrijf-reageert-verbaasd.html
https://www.nu.nl/tech/6056789/minister-legt-lek-infectieradar-bij-ontwikkelaar-bedrijf-reageert-verbaasd.html
"Marco Beuk van Formdesk laat in een reactie weten verbaasd te zijn over het verhaal van De Jonge. Volgens hem is de kwetsbaarheid niet eerder aan het licht gekomen en dus ook niet aan Formdesk teruggekoppeld."
Gezien de opzet in instructies voor het gebruik ziet het er inderdaad goed uit. Een login met van alles er om heen.
Aangezien de beveiliging in applicaties gebouwd moet worden en niet extern zit kan het wel eens misgaan.
Het web is niet ontworpen voor transacties en veiligheid van informatie.
Het web is niet ontworpen voor transacties en veiligheid van informatie.
Deze opmerking slaat nergens op. Het web is de verzameling van systemen, waarbij ieder systeem afzonderlijk veilig is of niet. Een systeem kan je prima veilig maken, als je je best maar doet.
Het web is niet ontworpen voor transacties en veiligheid van informatie.
Deze opmerking slaat nergens op. Het web is de verzameling van systemen, waarbij ieder systeem afzonderlijk veilig is of niet. Een systeem kan je prima veilig maken, als je je best maar doet.
Ik reageer even als meelezer.
Als je dat stelt dan vraag ik me af hoeveel je snapt van keten-werking.
Veiligheid houdt niet op bij koppelpunten tussen deze en gene systemen.
Het gaat er niet alleen om dat je systeem prima veilig kan maken, ook dat het volledig veilig blijft, dat je niet datgeen op het systeem plaatst dat je liever niet kwijt wilt raken, zoiets als nu tegen alle wijsheid in met dit lek uit verantwoordelijkheid van de Jonge gebeurt.
Als je dat meeneemt terwijl je naar transacties via allerlei koppelpunten kijkt, hoezo is het dan onzin als iemand aan de orde stelt of je veiligheid van systeem naar systeem een veiligheid issue is?
Kan je nader toelichten welk deel in die beschouwing niet relevant zou zijn?
klopt helemaal.
Deze opmerking slaat nergens op. Het web is de verzameling van systemen, waarbij ieder systeem afzonderlijk veilig is of niet. Een systeem kan je prima veilig maken, als je je best maar doet.
Een dbms kent een acid gebeuren voor de integriteit van gegevens .
Afhankellijk van het os en de configuratie identificatie en autorisatie voor accounts en autorisatie voor gegevens. Zie het verschil met het web. De frameworks mosten dat allemaal zelf opnieuw uitvinden.
Het is terug naar de jafen 90 toen de toenmalige frameworks dbms geen uitgebreide security hadden en alles uitgecodeerd werd in de applicaties. Een ontkoppeling is gewoon nodig ik zie het nog niet gebeuren.
Dit is weer een staaltje symptoombeoordeling van een gefabriceerd virus
Testen is bewijs vinden dat er fouten in zitten. Testen is niet bewijzen dat het foutvrij is.
Testen is het vaststellen van kwaliteit van software en het inschatten van de resterende risico's bij ingebruikname hiervan. Essentieel hierbij is het opstellen van fatsoenlijke kwaliteitscriteria. Op hoofdlijnen zullen die moeten komen van de opdrachtgever (die hiervoor idealiter wel wat kennis in huis heeft) en opdrachtgever en leverancier kunnen dit dan verder detailleren. Zodra de kwaliteitscriteria zijn opgesteld, weet je ook wat je moet gaan testen.
https://www.google.com/search?q=site%3Afd7.formdesk.com
Ongeveer 1.570 resultaten
klopt helemaal.
https://www.google.com/search?q=site%3Afd7.formdesk.com
Ongeveer 1.570 resultaten
Wel weer grappig is dat ze een security exploit bounty programma hebben: https://nl.formdesk.com/security-exploit-bounty-program/
klopt helemaal.
Probeer het eens in een DC3 of mosquito met een drukcabine. Dat het lukt ligt aan een geheel her ontwerp met standaardisatie. Met de 737 max heb je gezien hoe standaardisatie en veiligheid ten koste gegaan is voor het korte termijn geldelijk gewin. De nieuwe motor (een compleet herontwerp) past niet de body had beter ook herontworpen kunnen worden.
Duidelijk is dat enkel open source roepen in die complexe wereld van vele ketens gewoon niet werkt.
Het web is een commercieel succes geworden dat betekent niet dat de werking en veiligheid ook op orde is.
Dat is de grootste denkfout die je maakt. Omdat iedereen het doet moet het wel goed zijn.... Lemmingen in een matrix.
Als je dat stelt dan vraag ik me af hoeveel je snapt van keten-werking.
Veiligheid houdt niet op bij koppelpunten tussen deze en gene systemen.
Het gaat er niet alleen om dat je systeem prima veilig kan maken, ook dat het volledig veilig blijft, dat je niet datgeen op het systeem plaatst dat je liever niet kwijt wilt raken, zoiets als nu tegen alle wijsheid in met dit lek uit verantwoordelijkheid van de Jonge gebeurt.
Als je dat meeneemt terwijl je naar transacties via allerlei koppelpunten kijkt, hoezo is het dan onzin als iemand aan de orde stelt of je veiligheid van systeem naar systeem een veiligheid issue is?
Kan je nader toelichten welk deel in die beschouwing niet relevant zou zijn?
Dank u... ik ben benieuwd naar de inhoudelijke reacties.
Probeer het eens in een DC3 of mosquito met een drukcabine. Dat het lukt ligt aan een geheel her ontwerp met standaardisatie. Met de 737 max heb je gezien hoe standaardisatie en veiligheid ten koste gegaan is voor het korte termijn geldelijk gewin. De nieuwe motor (een compleet herontwerp) past niet de body had beter ook herontworpen kunnen worden.
Duidelijk is dat enkel open source roepen in die complexe wereld van vele ketens gewoon niet werkt.
Het web is een commercieel succes geworden dat betekent niet dat de werking en veiligheid ook op orde is.
Dat is de grootste denkfout die je maakt. Omdat iedereen het doet moet het wel goed zijn.... Lemmingen in een matrix.
Kern van de zaak: Dat iets een commercieel success is wil niet zeggen dat het veilig is. Ook niet onder de OSS vlag.
klopt helemaal.
Voeg dan wel ook even toe hoe je tegen de bezwijk mechanismen van web onderdelen aankijkt?
Zeker als je naar auto’s en vliegtuigen kijkt zie je dat de ingebouwde en toegevoegde veiligheid bij auto’s en vliegtuigen andere optimalisatie mogelijkheden hebben. Auto’s botsen gezien dat ze zeg maar allemaal op dezelfde hoogte als nabije auto’s verplaatsen eerder dan vliegtuigen. Marges voor reactie tijden bij vliegtuigen voor uitval of storing van onderdelen ook weer heel anders waardoor de veiligheid als geheel per auto / vliegtuig weer andere marges en borging kent.
Dan kan je ook nog kijken naar de ondersteunende systemen voor veiligheid.
Als je nou kijkt naar de zoveelste casus van uitval van het commerciele Vodafone waardoor de veiligheidsregio’s toch weer bereikbaarheid problemen bleken te hebben kan je je stelling voor het veilige web in dit verband dan nader verklaren?
Welke toepassing of commercieel onderdeel dat voor veiligheid in het web was toegevoegd zou jij dan nader naar kijken?
Mij lijkt de redudantie alsnog door minister van veiligheid Grapperhaus gewoon niet gefixt.
Hij stelde namelijk bij de vorige storing dat die per definitie KORTER dan een 1 uur duur moesten blijven.
Op die eis die Grapperhaus als eindverantwoordelijke niet zo lang geleden als onwrikbaar presenteerde, faalt het meld-systeem van zijn veiligheidsregio(‘s) vandaag dus opnieuw.
Aansluitend kan je misschien ook toelichten welk toe te voegen commercieel middel met veiligheid functie de achterwege gebleven verificatie van zoiets basic als url tweak bij de infectieradar website zeker had moeten voorkomen?
Url tweaking is toch wel zo basis onderdeel voor je laatste checks & balances voordat je live gaat naar het brede publiek
Ben erg nieuwsgierig naar je inzichten hieromtrent,
Testen is bewijs vinden dat er fouten in zitten. Testen is niet bewijzen dat het foutvrij is.
Testen is het vaststellen van kwaliteit van software en het inschatten van de resterende risico's bij ingebruikname hiervan. Essentieel hierbij is het opstellen van fatsoenlijke kwaliteitscriteria. Op hoofdlijnen zullen die moeten komen van de opdrachtgever (die hiervoor idealiter wel wat kennis in huis heeft) en opdrachtgever en leverancier kunnen dit dan verder detailleren. Zodra de kwaliteitscriteria zijn opgesteld, weet je ook wat je moet gaan testen.
Tja, dat is dan vooral de definitie van testen volgens een hofleverancier van ICT aan de overheid.
Debuggen doe je om fouten na te gaan voordat je de laatste fase van een ontwikkel en lancering traject bereikt.
Testen is meer dan debuggen en behelst ook een breder verhaal dan de kwaliteit van het ICT middel toetsen en vaststellen. Nadat de kwaliteit van het ICT middel vaststaat ben je er gewoon niet.
Enerzijds gaat het er wel om dat de ICT functioneert conform de specs, de (hoofd)eisen waarbij je kan afvragen of als dat voorgaande afgeleiden zijn je de top-eisen voor de oplossing goed kunt testen.
Een aangetoonde goede kwaliteit is van toepassing wanneer de oplossing heel strikt valt binnen de spes en (hoofd)eisen blijkt te vallen.
De impliciete - lees ingebakken en niet uit specs rechtsreeks afleidbare hiaten - en heel en zeer laakbaar opgetreden fouten vind je zover in het stadium niet snel op basis van je kwaliteit definities.
Waar een kwaliteitsgat nog enigszins onder de aandacht van kwaliteit beheersing valt heeft de beginnersfout van het ministerie m.b.t de virus radar te maken met een hiaat in het testen!
Zo mogelijk door te snel over te gaan naar de volgende stap of sprint, maar in ieder geval waren eerdere testen evident onvoldoende.
Dan mag iedereen zelf nagaan of het onvoldoende was door een minister die zaken in de wind heeft geslagen, tijd afknibbelde van het testen of dat er iets anders speelde.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?