Opnieuw Kamervragen over beveiligingslek Infectieradar
Er zijn opnieuw Kamervragen aan minister De Jonge van Volksgezondheid gesteld over het beveiligingslek in Infectieradar waardoor eenvoudig medische gegevens van deelnemers konden worden bekeken. VVD-Kamerlid Veldman wil opheldering van de minister, nadat die liet weten dat de ontwikkelaar op de hoogte van het beveiligingslek was, terwijl de ontwikkelaar dit op zijn beurt ontkende. Eerder vroeg ook GroenLinks al om opheldering.
Door een kwetsbaarheid in de vragenformulierapplicatie van Infectieradar bleek het zeer eenvoudig om medische gegevens van andere gebruikers in te zien. De minister maakte vorige week bekend dat de ontwikkelaar wist van het beveiligingslek en was gevraagd om dit te verhelpen. Dit was echter niet gebeurd en doordat er geen "dubbelcheck" had plaatsgevonden was het beveiligingslek niet verholpen, aldus De Jonge. Formdesk, het softwarebedrijf waarvan de vragenformulierapplicatie door Infectieradar wordt gebruikt, liet in een reactie weten dat de kwetsbaarheid niet eerder aan het licht was gekomen en ook niet bij het bedrijf was gemeld.
"Hoe beoordeelt u de uitspraken van Formdesk dat de kwetsbaarheid niet eerder aan het licht is gekomen en ook niet aan Formdesk teruggekoppeld is?", vraagt Veldman, die tevens wil weten welke andere kwetsbaarheden bij de veiligheidscheck van Infectieradar aan het licht zijn gekomen. Minister De Jonge moet daarnaast duidelijk maken hoe hij het vertrouwen van gebruikers gaat herstellen.
Veldman wil ook duidelijkheid of het datalek gevolgen gaat hebben op de bereidheid van mensen om zich voor het donorregister te registreren. "Heeft het datalek in de infectieradar ook effect op alle Nederlanders boven de 18 jaar die hun keuze met het oog op het registreren in het nieuwe donorregister nog moeten maken? Met andere woorden: heeft dit datalek een negatief effect op de bereidheid van de mensen om zich te registreren?", aldus het Kamerlid. De minister heeft drie weken de tijd om de vragen te beantwoorden.
Zo hebben ze (compliment!) een BugBounty programma https://nl.formdesk.com/security-exploit-bounty-program/, maar is er geen demo-omgeving waar je zelf even los kunt gaan.
Dus hierbij de oproep aan alle bedrijven: zorg dat je BugBounty programma ook voorzien is van de mogelijkheden om te testen. Richt die test-server even in of zorg dat je als tester in productie alles kunt testen.
Het levert echt veel op, onderzoekers vinden het leuk en niets gevonden = geen kosten = kunnen claimen dat het aardig veilig moet zijn.
Dat doet overigens niets af aan het feit dat minister de Jonge toch als eindverantwoordelijke de website zelf nooit op deze wijze nooit live had mogen laten.
Als je iets checkt, zeker waar het onhebbelijkheden met betrekking tot privacy of andere top-risico's betreft, dan vergewis je je ervan dat het ZEKER is opgelost.
Dan zeg je niet quasi achteraf dat iets met de dubbelcheck niet helemaal goed ging.
Het vergewissen doe je door middel van toetsing.
Kennelijk heeft minister de Jonge dus niet goed toegezien op het verhelpen van een onverkwikkelijk gebrek, of hij heeft het destijds zelf door de vingers proberen te kijken.
In dat laatste geval heeft minister de Jonge natuurlijk helemaal ontoelaatbaar schandalig gehandeld door de privacy beginselen in de basis zo op de proef te stellen. Dan heb je de wet misschien wel in gedachten en intentie willen toepassen maar heb je dat uiteindelijk bewust en/of doelbewust nagelaten.
Voor "het zelf niet toepassen van de gehele wet op de privacy" kunnen volgens de minister die de AP en AVG destijds instelde op voorhand eigenlijk geen excuses volstaan.
Gezien de hoeveelheid blunders van deze minister zou ik verbaasd zijn als het CDA hem als fractieleider gaan kiezen. De kans is aanwezig dat hij zelf het veld moet ruimen met de verkeerde voorlichting van de tweede kamer en de gebrekkige opzet van "de app".
Zo hebben ze (compliment!) een BugBounty programma https://nl.formdesk.com/security-exploit-bounty-program/, maar is er geen demo-omgeving waar je zelf even los kunt gaan.
Ik zit even de "regels" te lezen maar ze spreken zichzelf tegen (of ben ik nou gek).
Bovenaan:
Access or expose only customer data that is your own.
Onderaan:
We will only qualify and reward a vulnerability if and only if the bug can be successfully used by itself or in combination with another vulnerability you report to access user data that is not yours.
Weird? Of mis ik wat?
Zo hebben ze (compliment!) een BugBounty programma https://nl.formdesk.com/security-exploit-bounty-program/, maar is er geen demo-omgeving waar je zelf even los kunt gaan.
Ik zit even de "regels" te lezen maar ze spreken zichzelf tegen (of ben ik nou gek).
Bovenaan:
Access or expose only customer data that is your own.
Onderaan:
We will only qualify and reward a vulnerability if and only if the bug can be successfully used by itself or in combination with another vulnerability you report to access user data that is not yours.
Weird? Of mis ik wat?
Niet weird: (a) je mag geen klantdata benaderen of publiek maken; (b) via een bug moet je user data kunnen benaderen die niet van jou is.
Je kan (b) aantonen met je eigen data door bv. twee accounts aan te maken en de data van de ene vanuit de andere te benaderen via een bug. Maar je mag voor het vinden van de bug voor (b) en het demonstreren daarvan geen gebruik maken van data van anderen of die publiek maken.
Niet weird: (a) je mag geen klantdata benaderen of publiek maken; (b) via een bug moet je user data kunnen benaderen die niet van jou is.
Je kan (b) aantonen met je eigen data door bv. twee accounts aan te maken en de data van de ene vanuit de andere te benaderen via een bug. Maar je mag voor het vinden van de bug voor (b) en het demonstreren daarvan geen gebruik maken van data van anderen of die publiek maken.
Bij vinden/zoeken van problemen en fouten:
- Alleen je eigen gegevens als verwerkersverantwoordelijke daarvoor gebruiken.
- Als je een gedegen informatievoorziening ontwikkeling, acceptatietesten, operatie (productie) hebt moet zoiets vrijwel vanzelf gaan. Reden: Je hebt niets met andermans data te maken. Probleem: de incidentele hacker werkt niet op die wijze.
In het aan te leveren bewijs:
- Gebruik geen echte productie gegevens maar niet herleidbare speciale testgegevens.
Reden: de SAAS dienstverlener wil geen productiegegevens kunnen zien van klanten afnemers. privacy / gevoeligheden.
Het lijkt me redelijk basaal hoe je professioneel hoort te werken. Dat de klant / gebruiker ook iets ontwikkelt en dat zelf goed hoort te testen is een behoorlijk pijnpunt. Het kan zijn dat niet de leverancier fout zit maar de werkwijze bij de afnemer de werkelijke oorzaak is.
- we gaan geen login en gebruikers van de enquete doen. Geeft een boel problemen en mogelijk een datalek.
- Zorg maar dat je de enquetes / formulieren op een gemakkelijke manier laat invullen
- Goh, er is geen onderscheid tussen gebruikers van de formulieren, dat had iemand anders moeten doen.
Het is een scenario, ik ben benieuwd naar de antwoorden en wat de waarheid is.
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
