RIVM: beveiligingslek Infectieradar ondanks controles niet ontdekt
Het beveiligingslek in de Infectieradar van het Rijksinstituut voor Volksgezondheid en Milieu (RIVM) waardoor het zeer eenvoudig was om medische gegevens van deelnemers in te zien is ondanks verschillende veiligheidschecks niet ontdekt. Dat laat het RIVM in een nieuwe verklaring weten. De Autoriteit Persoonsgegevens is inmiddels over het datalek geïnformeerd.
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 voor derden toegankelijk, zo werd dit weekend duidelijk.
Deelnemers aan Infectieradar krijgen een uniek nummer van acht cijfers, dat bij het invullen van de vragenlijst zichtbaar in de adresbalk van de browser was. Door het wijzigen van dit cijfer in de adresbalk was het mogelijk om het formulier van iemand anders te bekijken. Een kwetsbaarheid die ook bekend staat als Insecure Direct Object Reference (IDOR). Via een script zou het zo eenvoudig mogelijk zijn om gegevens van allerlei andere gebruikers te verzamelen. Nadat het datalek was gemeld besloot het RIVM de database offline te halen.
"De gegevens van deelnemers aan Infectieradar zijn door niemand anders ingezien dan door de journalist en de aan hen meldende beveiligingsexpert", zo stelt het RIVM. Het ging om 49 aanmeldformulieren, waarvan de journalist en de beveiligingsonderzoeker hebben laten weten de gegevens zo snel mogelijk te zullen vernietigen.
Het RIVM heeft een melding gedaan bij de Autoriteit Persoonsgegevens van het datalek en alle deelnemers ingelicht waarvan de gegevens zijn ingezien. Volgens het Rijksinstituut waren er verschillende veiligheidschecks op de gebruikte software uitgevoerd, maar was het beveiligingslek niet aan het licht gekomen. We hebben het RIVM gevraagd om wat voor soort checks het precies ging en zullen het artikel bijwerken zodra we een reactie krijgen.
Afsluitend meldt het Rijksinstituut dat de softwareleverancier inmiddels een oplossing heeft doorgevoerd die zowel door het RIVM als een externe partij wordt getest. "Zodra we zeker weten dat de vragenlijsten veilig worden opgeslagen, gaan we 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.
Reacties (25)
09-06-2020, 08:08 door
Erik van Straten
Het RIVM heeft vermoedelijk een capabele derde partij ingehuurd voor het checken van de site (weet iemand welk bedrijf dat is?) - het RIVM zal een derde securityissue met deze site willen voorkomen.
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Intussen is meer bekend: https://www.computable.nl/artikel/nieuws/security/6939961/250449/rivm-wacht-met-herlancering-infectieradar-na-datalek.html Het gaat om een framework zoals Wordpress of Magento voor formulieren. In de link hierboven is Formdesk genoemd, Daarvan zijn meer links bij het RIVM en bij meerdere partijen te vinden.Het wordt ook bij universiteiten (Leiden Utrecht) ingezet. Het achterliggende bedrijfje (ca 10 werknemers, 2000 afnemers) bestaat al 20 jaar. Ze doen het als een SAAS dat betekent dat de klant alleen de opmaak aangeeft, de hele verwerking wordt door innovera gedaan. Na de verwerking door formdesk (innovera) worden de gegevens teruggestuurd naar de klant.
Bedenk RIVM is maar één van de vele klanten.
De problematiek wordt nu helderder.
- een login bij het RIVM (enquete formulier invullen) is zeer moeilijk veilig te propageren naar formdesk.
- een verwerkingsprobleem in formdesk is via een CVD (voorheen responsible disclosure).https://www.ncsc.nl/documenten/publicaties/2019/mei/01/cvd-leidraad lastig door de vele niet zichtbare partijen.
+ Het Rivm doet enkel de analyses houdt zich verre van de techniek.
+ SSC-campus doet de meeste techniek voor het rivm maar niet wat via SAAS bij andere partijen loopt
+ Al deze partijen zijn niet direct zichtbaar voor iemand aan de buitenkant
Het laagdrempelig zijn van meldingen is niet op orde.Het advies om voor het melden een formulier te gebruiken heeft in dit geval iets van kafka. Het is de externe dienstverlener voor formulieren war het mis gegaan is.
Link uni leiden:
https://www.medewerkers.universiteitleiden.nl/ict/ict-werkplek/software-en-samenwerkingstools/webformulieren-maken
"Met Formdesk kun je online formulieren maken. De tool gebruik je voor inschrijvingen voor evenementen en het opvragen van feedback. Je vraagt een account aan via de ISSC Helpdesk.
Inloggen
Log in op Formdesk met je Formdesk-account."
Link uni Utrecht
https://www.formdesk.nl/universiteitutrecht
Als de mensen van de universiteiten nooit iets van het datalek gemerkt hebben, dan moet het wel een erg bijzonder iets zijn. Die situatie draagt niet bij in het accepteren van kunnen melden van softwarefouten.
Het is gelukkig geen dienstverlener die een dominante positie in de markt heeft.. Het zal snel opgepakt worden.
@Erik je vraag is hierbij beantwoord, ik werkte aan deze tekst voordat je post zichtbaar was. … vooruitzien ….
IK ben me nog aan het verbazen over wie er nog meer gebruik van maakt.
De voorbeeldformulieren geven een aardige indruk van de klanten en het soort gebruik.
Deze ligt er bij het RIVM nu ook uit:
https://magazines.rivm.nl/2018/07/magazine-omgevingsveiligheid/nieuwe-versie-handboek-omgevingsveiligheid
Je moet een formulier invullen om dat handboek te krijgen.
Bedenk RIVM is maar één van de vele klanten.
De problematiek wordt nu helderder.
- een login bij het RIVM (enquete formulier invullen) is zeer moeilijk veilig te propageren naar formdesk.
- een verwerkingsprobleem in formdesk is via een CVD (voorheen responsible disclosure).https://www.ncsc.nl/documenten/publicaties/2019/mei/01/cvd-leidraad lastig door de vele niet zichtbare partijen.
+ Het Rivm doet enkel de analyses houdt zich verre van de techniek.
+ SSC-campus doet de meeste techniek voor het rivm maar niet wat via SAAS bij andere partijen loopt
+ Al deze partijen zijn niet direct zichtbaar voor iemand aan de buitenkant
Het laagdrempelig zijn van meldingen is niet op orde.Het advies om voor het melden een formulier te gebruiken heeft in dit geval iets van kafka. Het is de externe dienstverlener voor formulieren war het mis gegaan is.
Link uni leiden:
https://www.medewerkers.universiteitleiden.nl/ict/ict-werkplek/software-en-samenwerkingstools/webformulieren-maken
"Met Formdesk kun je online formulieren maken. De tool gebruik je voor inschrijvingen voor evenementen en het opvragen van feedback. Je vraagt een account aan via de ISSC Helpdesk.
Inloggen
Log in op Formdesk met je Formdesk-account."
Link uni Utrecht
https://www.formdesk.nl/universiteitutrecht
Als de mensen van de universiteiten nooit iets van het datalek gemerkt hebben, dan moet het wel een erg bijzonder iets zijn. Die situatie draagt niet bij in het accepteren van kunnen melden van softwarefouten.
Het is gelukkig geen dienstverlener die een dominante positie in de markt heeft.. Het zal snel opgepakt worden.
@Erik je vraag is hierbij beantwoord, ik werkte aan deze tekst voordat je post zichtbaar was. … vooruitzien ….
IK ben me nog aan het verbazen over wie er nog meer gebruik van maakt.
De voorbeeldformulieren geven een aardige indruk van de klanten en het soort gebruik.
Deze ligt er bij het RIVM nu ook uit:
https://magazines.rivm.nl/2018/07/magazine-omgevingsveiligheid/nieuwe-versie-handboek-omgevingsveiligheid
Je moet een formulier invullen om dat handboek te krijgen.
Grappig hoe iets simpels als een formuliertje, door de vele derde partijen en de vele vele lagen software en vooral dat niemand nog weet wat iemand van de rest nog doet, tot een beheers- en beveiligingsnachtmerrie wordt. Dat soort problematiek heeft papier veel minder.
ik vraag me af of de term lek hier op zijn plaats is. Een lek is in mijn beleving iets dat er niet is totdat het door een onvoorziene gebeurtenis ontstaat. Hier lijkt sprake van een constructiefout die al vanaf het begin bestaat. Alsof een aannemer bij alle appartementen in een appartementengebouw dezelfde cilindersloten op alle voordeuren heeft geplaatst.
@karma4
Een Karma4 onwaardige bijdrage, deze is leesbaar, nagenoeg geen taalfouten, geen directe FOSS bashing.
Niet gewend van je, ga zo door. :-)
Een "capabele partij" die niet test op IDOR is als een viroloog die beweert dat bronwater het middel is tegen Covid-19.
Een Karma4 onwaardige bijdrage, deze is leesbaar, nagenoeg geen taalfouten, geen directe FOSS bashing.
Niet gewend van je, ga zo door. :-)
Een "capabele partij" die niet test op IDOR is als een viroloog die beweert dat bronwater het middel is tegen Covid-19.
Een dergelijke IDOR fout is bepaald geen onbekende. Tien jaar geleden stond deze nog op #4 in de OWASP top 10 (https://blog.securelayer7.net/owasp-top-10-4-insecure-direct-object-reference-vulnerability/). Triest genoeg zijn die veel voorkomende fouten even vermijdbaar als onuitroeibaar. Maar dat maakt het nog geen excuus.
Je kan je ook nadrukkelijk afvragen wat de informatiebeveiliging waard is als RIVM diverse beveiligingschecks claimt te hebben uitgevoerd, en geen enkele daarvan kijkt blijkbaar naar het archief van de meest geaccepteerde top 10 van beveiligingslekken ter wereld...
Wat erger is: Zo moeilijk is het niet om een web pagina als geheel te downloaden met een commando of script. Combineer dit met een IDOR fout en een oplopend volgnummer en presto, je hebt de hele administratie in minder dan een kwartiertje en kan op je luie stoel in Verweggistan op je gemak gaan uitzoeken wat er van je gading bij zit...
Je kan je ook nadrukkelijk afvragen wat de informatiebeveiliging waard is als RIVM diverse beveiligingschecks claimt te hebben uitgevoerd, en geen enkele daarvan kijkt blijkbaar naar het archief van de meest geaccepteerde top 10 van beveiligingslekken ter wereld...
Wat erger is: Zo moeilijk is het niet om een web pagina als geheel te downloaden met een commando of script. Combineer dit met een IDOR fout en een oplopend volgnummer en presto, je hebt de hele administratie in minder dan een kwartiertje en kan op je luie stoel in Verweggistan op je gemak gaan uitzoeken wat er van je gading bij zit...
Door Erik van Straten: Het RIVM heeft vermoedelijk een capabele derde partij ingehuurd voor het checken van de site (weet iemand welk bedrijf dat is?) - het RIVM zal een derde securityissue met deze site willen voorkomen.
Er staat nu dat "de oplossing wordt getest". Laten we hopen dat ze bedoelen "ge-audit", want met testen kun je zoiets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Dit soort pakketten is vaak meer geschikt voor een intranet omgeving waarbij de gebruikers onderling wel min of meer
te vertrouwen zijn, en zelfs dan nog zijn ze eigenlijk niet geschikt voor gevoelige data (of dat nou persoonsgegevens zijn
of andere zaken die geheim moeten blijven)
We hebben op het werk een ander pakket, maar dat slaat formulierdata op in een Sharepoint lijst. Iedereen die toegang
heeft, heeft toegang tot de hele lijst (geen row-level authenticatie) en dus kun je altijd bij de gegevens die anderen hebben
ingevuld in hetzelfde formulier, op zijn minst tot die "verwerkt en weer verwijderd" zijn.
Voor veel toepassingen helemaal niet erg, maar je loopt snel tegen problemen aan en helaas verwatert de routine van
"eerst checken of dit tool wel ingezet kan worden in dit geval" natuurlijk al snel.
te vertrouwen zijn, en zelfs dan nog zijn ze eigenlijk niet geschikt voor gevoelige data (of dat nou persoonsgegevens zijn
of andere zaken die geheim moeten blijven)
We hebben op het werk een ander pakket, maar dat slaat formulierdata op in een Sharepoint lijst. Iedereen die toegang
heeft, heeft toegang tot de hele lijst (geen row-level authenticatie) en dus kun je altijd bij de gegevens die anderen hebben
ingevuld in hetzelfde formulier, op zijn minst tot die "verwerkt en weer verwijderd" zijn.
Voor veel toepassingen helemaal niet erg, maar je loopt snel tegen problemen aan en helaas verwatert de routine van
"eerst checken of dit tool wel ingezet kan worden in dit geval" natuurlijk al snel.
Volgens de infectieradar zijn mijn gegevens niet uitgelekt. Ik ben benieuwd wanneer ik de eerste spam ontvang op het unieke e-mailadres waarmee ik geregistreerd heb.
Door Anoniem: Volgens de infectieradar zijn mijn gegevens niet uitgelekt. Ik ben benieuwd wanneer ik de eerste spam ontvang op het unieke e-mailadres waarmee ik geregistreerd heb.
Dat lijkt mij interessant. In zo'n geval zou ik het aantal 'hits' hier even posten.Door Erik van Straten: Het RIVM heeft vermoedelijk een capabele derde partij ingehuurd voor het checken van de site (weet iemand welk bedrijf dat is?) - het RIVM zal een derde securityissue met deze site willen voorkomen.
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Hoe kan het na al deze veiligheidschecks, dat IDOR over het hoofd is gezien aangezien dit al jaren bij de overheid voorkomt? (lees: het lekken van de Miljoenennota in de verschillende jaren).Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Er zijn twee mogelijkheden:
1) De veiligheidschecks zijn uitgevoerd door niet-capabele mensen
2) De checks zijn slecht, verkeerd, niet, of maar gedeeltelijk uitgevoerd.
Het is nu maar wachten op het antwoord.
09-06-2020, 11:36 door
Goeroeboeroe
Door Anoniem: Volgens de infectieradar zijn mijn gegevens niet uitgelekt. Ik ben benieuwd wanneer ik de eerste spam ontvang op het unieke e-mailadres waarmee ik geregistreerd heb.
Ik heb ook zo'n mail gekregen. M'n rug op. Gezien de stupiditeit van de fout meld ik mij bij de eerste nieuwe vraag om gegevens af. Wie zegt mij dat er niet nog 'n berg van dat soort fouten in zit?Door Anoniem:
iets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Het is maar wat je als definitie van testen en auditten neemt. Overigens vind ik "auditten" nog sterker dan "testen" het verifiëren dat iets aan vooraf gedefinieerde criteria voldoet. Immers, bij "pentesten" hebben de onderzoekers vaak veel vrijheden in wat ze precies testen (vaak wel timeboxed). Zelf hanteer ik graag de term "assessment" voor een onderzoek waarbij niet bij voorbaat vaststaat wat er precies onderzocht gaat worden.Door Erik van Straten: Het RIVM heeft vermoedelijk een capabele derde partij ingehuurd voor het checken van de site (weet iemand welk bedrijf dat is?) - het RIVM zal een derde securityissue met deze site willen voorkomen.
Er staat nu dat "de oplossing wordt getest". Laten we hopen dat ze bedoelen "ge-audit", want met testen kun je zoiets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Overigens garandeert geen enkele methode dat je alle kwetsbaarheden vindt. Maar kwetsbaarheden van het type IDOR zijn dusdanig goed gedocumenteerd dat ze bij elke webapptest op de checklist horen te staan, en dus ontdekt hadden moeten worden.
Door karma4: Intussen is meer bekend: https://www.computable.nl/artikel/nieuws/security/6939961/250449/rivm-wacht-met-herlancering-infectieradar-na-datalek.html Het gaat om een framework zoals Wordpress of Magento voor formulieren. In de link hierboven is Formdesk genoemd,
Dank voor die link.Er zal wel een scan zijn gemaakt met een of andere leuke tool. Tools zijn niet geschikt voor het vinden van IDO's, dat is echt mensen werk. Net als logic en hor/ver privilege escalation.
Door Anoniem:
iets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Door Erik van Straten: Het RIVM heeft vermoedelijk een capabele derde partij ingehuurd voor het checken van de site (weet iemand welk bedrijf dat is?) - het RIVM zal een derde securityissue met deze site willen voorkomen.
Er staat nu dat "de oplossing wordt getest". Laten we hopen dat ze bedoelen "ge-audit", want met testen kun je zoiets nooit goed en veilig krijgen.
(in het algemeen kun je al stellen dat je met testen wel kunt aantonen dat iets niet deugt, maar niet dat het OK is)
Ook met audits kun je dat niet.
09-06-2020, 13:08 door
souplost
Nu ligt het ineens aan de ontwikkelaars (allemaal!).
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Door souplost: Nu ligt het ineens aan de ontwikkelaars (allemaal!).
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Beheerder ontwikkelaar wat maakt het uit. Wat mis gegaan is dat bij uitbestedende partij (beheer) onvoldoende zicht op de betrouwbaarheid informatieveiligheid is. Bij de uitvoerende partij is iets mis gegaan in het sessie management gebeuren dat alles in de ene met een login verbonden persoon moet blijven. Zo kijkend in handleidingen zie ik dat ze er wel kennis hebben wat de eisen zijn. Er is ergens met de realisatie wat mis gegaan. Dat had een beheerder met een test er uit moeten halen. Als je weet wat sessies moeten doen (scheiding gegevens) dan kan je dat controleren.Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Dit moet In het framework (de applicatie) gedaan worden, html en het os bieden niets.
Ik hoor het riedeltje van argumenten waarom er niet gekeken mag worden. Toch verbazend het brede gebruik zelfs bij universiteiten en dat tot nu toe niemand wat opgevallen is.
Door Erik van Straten: Het RIVM heeft vermoedelijk een capabele derde partij ingehuurd voor het checken van de site (weet iemand welk bedrijf dat is?) - het RIVM zal een derde securityissue met deze site willen voorkomen.
Met fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
Binnen de overheid worden dit soort sites geaudit door rijks audit dienstMet fouten als IDOR ligt het voor de hand dat de ontwikkelaars geen verstand hebben van security en het om een gatenkaas gaat. Als mijn vermoeden klopt en er vakkundige securitytesters op gezet zijn, kan het nog wel even duren voordat deze site weer online is...
https://www.rijksoverheid.nl/onderwerpen/rijksoverheid/auditbeleid/auditdiensten
waarschijnlijk stond er geen productie data op of ingevulde gegevens of van maar één gebruiker.
Door karma4:
Dit moet In het framework (de applicatie) gedaan worden, html en het os bieden niets.
Ik hoor het riedeltje van argumenten waarom er niet gekeken mag worden. Toch verbazend het brede gebruik zelfs bij universiteiten en dat tot nu toe niemand wat opgevallen is.
Door souplost: Nu ligt het ineens aan de ontwikkelaars (allemaal!).
Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Beheerder ontwikkelaar wat maakt het uit. Wat mis gegaan is dat bij uitbestedende partij (beheer) onvoldoende zicht op de betrouwbaarheid informatieveiligheid is. Bij de uitvoerende partij is iets mis gegaan in het sessie management gebeuren dat alles in de ene met een login verbonden persoon moet blijven. Zo kijkend in handleidingen zie ik dat ze er wel kennis hebben wat de eisen zijn. Er is ergens met de realisatie wat mis gegaan. Dat had een beheerder met een test er uit moeten halen. Als je weet wat sessies moeten doen (scheiding gegevens) dan kan je dat controleren.Ik ken een bedrijf die kapitale fouten maakt en dan ligt het hier op security.nl altijd aan de beheerders.
Dit moet In het framework (de applicatie) gedaan worden, html en het os bieden niets.
Ik hoor het riedeltje van argumenten waarom er niet gekeken mag worden. Toch verbazend het brede gebruik zelfs bij universiteiten en dat tot nu toe niemand wat opgevallen is.
ik kan je vertellen dat een std IT dienst van een universiteit niet de top-notch computer savy tech IT dienst is. de echte goede ITers op een uni zitten eerder bij wetenschappelijke groepen en hebben 'dr' voor hun naam staan. de centrale ITers zijn vaak gesjeede studenten of oude uitvallers of spul dat het in de commerciele IT wereld niet meer trekt / redt. ook is menig IT dienst bij een uNi opgezet met std (voornamelijk windows) beheerders en wordt voor elk moeilijk appart iets een smak geldt uitgezet naar extrene consultants. van die laatst groep heb je ook van alles tussen het vlugge-neefje tot aan een clubje juniors van een grotere gerenomeerde toko die seniors beloofd heeft, maarja, krijg je in de praktijk dan niet. soms zit er een enkele capable zzper zo maar per ongeluk tussen die dan na een maand of twee weer hard weg rent omdat er vooral veel politiek door management gedaan wordt in de uitgeholde dienst zelf. ik weet dat dit bij bedrijven vaak niet anders is.
09-06-2020, 17:51 door
karma4
Door Anoniem: .... en wordt voor elk moeilijk appart iets een smak geldt uitgezet naar extrene consultants. van die laatst groep heb je ook van alles tussen het vlugge-neefje tot aan een clubje juniors van een grotere gerenomeerde toko die seniors beloofd heeft, maarja, krijg je in de praktijk dan niet. soms zit er een enkele capable zzper zo maar per ongeluk tussen die dan na een maand of twee weer hard weg rent omdat er vooral veel politiek door management gedaan wordt in de uitgeholde dienst zelf. ik weet dat dit bij bedrijven vaak niet anders is.
Dat is de standaard en je had het daarbij kunnen laten.
Windows beheer kost geld uni's zijn bolwerken van goedkoop en dat anderen het wel doen. Beheer tja was dat niet iets vervelends wasr je niet in opleid en liever niets aan doet.
Reageren
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.
