Internet.nl test of websites aan TLS-richtlijnen NCSC voldoen
Er is een nieuwe versie van Internet.nl gelanceerd die nu ook kan testen of websites en mailservers aan de TLS-richtlijnen van het Nationaal Cyber Security Centrum (NCSC) van het ministerie van Justitie en Veiligheid voldoen. Internet.nl is een testtool van het Platform Internetstandaarden dat als doel heeft om het gebruik van moderne internetstandaarden verder te vergroten.
Internet.nl controleerde al op allerlei zaken en heeft nu ook de nieuwste TLS-richtlijnen van het NCSC toegevoegd. In april van dit jaar publiceerde de overheidsinstantie een nieuwe versie van de richtlijnen om rekening te houden met de ontwikkeling van de TLS-standaard. De nieuwe richtlijnen bieden configuraties op basis van TLS 1.3, dat de nieuwste versie van het TLS-protocol is. Daarnaast wordt aangeraden om bepaalde configuraties uit te faseren, zoals TLS 1.0, TLS 1.1 en 3DES en algoritmes voor statische sleuteluitwisselingen. Via Internet.nl kunnen organisaties nu eenvoudig controleren of hun mailserver of website hieraan voldoet.
Het Platform Internetstandaarden stelt dat behoorlijk wat mailservers alleen oudere TLS-versies ondersteunen. "Als de verzendende en ontvangende mailserver niet allebei dezelfde TLS-versie ondersteunen, dan zullen ze doorgaans terugvallen op onversleuteld transport. Om die reden kan het raadzaam zijn om de TLS-versies met status 'uit te faseren' voorlopig te blijven ondersteunen. Maak op basis van loggegevens een weloverwogen keuze voor het uitzetten van deze 'uit te faseren' TLS-versies."
Reacties (20)
Het probleem van die site is dat ze iedere waan van de dag erbij zetten waardoor allerlei configuraties die op zich prima
zijn toch altijd wel ergens een waarschuwing krijgen. Dan wordt je site bijvoorbeeld afgekeurd omdat deze compressie
ondersteunt, terwijl dat in de meeste gevallen totaal geen probleem is en alleen in een heel specifiek niche geval kan
worden gebruikt om iets naars te doen.
Ook is het jammer dat je geen volledige URL kunt opgeven maar alleen een domeinnaam, en als dan een redirect volgt
dan geeft ie niet de resultaten van die oorspronkelijke host maar van de host waarheen geredirect wordt (zonder dat
in de resultaten te melden). Het is daardoor onmogelijk om wat complexere setups te testen.
zijn toch altijd wel ergens een waarschuwing krijgen. Dan wordt je site bijvoorbeeld afgekeurd omdat deze compressie
ondersteunt, terwijl dat in de meeste gevallen totaal geen probleem is en alleen in een heel specifiek niche geval kan
worden gebruikt om iets naars te doen.
Ook is het jammer dat je geen volledige URL kunt opgeven maar alleen een domeinnaam, en als dan een redirect volgt
dan geeft ie niet de resultaten van die oorspronkelijke host maar van de host waarheen geredirect wordt (zonder dat
in de resultaten te melden). Het is daardoor onmogelijk om wat complexere setups te testen.
Ik kijk daar iets anders tegenaan. Je bepaalt zelf (als eigenaar / beheerder) natuurlijk je risicobereidheid. Dus wanneer jij vindt dat bepaalde gefaalde testen in de praktijk voor jou een laag risico vormen, dan kun je dat risico voor jezelf accepteren. Internet.nl zorgt er dan in ieder geval voor dat je bewust een risico kan accepteren, zodat je het niet onbewust loopt. Maar bedenk tegelijkertijd ook dat veel risico's niet alleen voor jezelf zijn, maar juist ook voor de gebruikers van je online diensten. En deze gebruikers hebben mogelijk een afwijkende risicobereidheid. Daarom vind ik het doorgaans wel verstandig om als eigenaar/hoster je verantwoordelijkheid te nemen en te zorgen voor een veilige opzet van je dienstverlening.
Het opgeven van een volledige URL heeft weinig nut, omdat veel standaarden op (sub)domeinniveau worden toegepast. Headers vormen hierop een uitzondering. HSTS dient te worden geplaatst op elke (sub)domein over HTTPS, omdat browsers dit ook per subdomein opslaan. Voor de overige headers is het niet handig om redirects te volgen, omdat verschillende (sub)domeinen dan elkaars testresultaten gaan beïnvloeden. Dat kan bijzonder vervelend zijn wanneer eigenaarschap van verschillende (sub)domeinen elders zijn belegd. Ik vind het dan ook het meest zuiver om redirect (sub)domeinen separaat te testen.
Het opgeven van een volledige URL heeft weinig nut, omdat veel standaarden op (sub)domeinniveau worden toegepast. Headers vormen hierop een uitzondering. HSTS dient te worden geplaatst op elke (sub)domein over HTTPS, omdat browsers dit ook per subdomein opslaan. Voor de overige headers is het niet handig om redirects te volgen, omdat verschillende (sub)domeinen dan elkaars testresultaten gaan beïnvloeden. Dat kan bijzonder vervelend zijn wanneer eigenaarschap van verschillende (sub)domeinen elders zijn belegd. Ik vind het dan ook het meest zuiver om redirect (sub)domeinen separaat te testen.
Ik vind het altijd wel jammer dat Internet.nl z'n stokpaardje IPv6 zo nodig moet promoten: Daardoor maakt je website nog geen onderdeel uit van het moderne internet. IPv6 staat (vrijwel volledig) los van al die goede beveiligingstests die er allemaal in staan. Minimaal zou je de optie willen geven om dit optioneel te includen
“ Als de verzendende en ontvangende mailserver niet allebei dezelfde TLS-versie ondersteunen, dan zullen ze doorgaans terugvallen op onversleuteld transport.”
Mogelijk is het toch verstandig als grote mailpartijen eens gaan stoppen met mailen over onversleutelde verbindingen. Dan worden beheerders wat meer gedwongen dit op te lossen. Of dat je dit tenminste terugziet (gmail doet dat met een slot icoon).
Mogelijk is het toch verstandig als grote mailpartijen eens gaan stoppen met mailen over onversleutelde verbindingen. Dan worden beheerders wat meer gedwongen dit op te lossen. Of dat je dit tenminste terugziet (gmail doet dat met een slot icoon).
Door Anoniem: Ik kijk daar iets anders tegenaan. Je bepaalt zelf (als eigenaar / beheerder) natuurlijk je risicobereidheid. Dus wanneer jij vindt dat bepaalde gefaalde testen in de praktijk voor jou een laag risico vormen, dan kun je dat risico voor jezelf accepteren. Internet.nl zorgt er dan in ieder geval voor dat je bewust een risico kan accepteren, zodat je het niet onbewust loopt. Maar bedenk tegelijkertijd ook dat veel risico's niet alleen voor jezelf zijn, maar juist ook voor de gebruikers van je online diensten.
Wij hebben bijvoorbeeld een bedrijfs website waarop alleen informatie te zien is en waar je als gebruiker geen account
kunt aanmaken. Het verste dat je kunt gaan is het invullen van een formulier met een contactaanvraag.
In een dergelijke context is het hameren op "je mag geen compressie doen" echt onzin.
Het klopt dat je die afweging zelf kunt maken, maar daarmee voorkom je niet dat anderen voor jou even jouw domein
invullen en gaan kwetteren dat de site onveilig is. Terwijl dat dus helemaal niet zo hoeft te zijn.
Het opgeven van een volledige URL heeft weinig nut, omdat veel standaarden op (sub)domeinniveau worden toegepast.
Ik zal een voorbeeld geven. Je hebt bijvoorbeeld het domein example.com en je draait een website www.example.com
die je hebt ondergebracht bij een externe webhoster, daarnaast heb je een machine waarop je example.com
uitkomt. Dit zijn dus 2 verschillende machines (2 verschillende hosting omgevingen zelfs).
Om mensen die www niet intikken te helpen heb je op toplevel van je example.com machine een redirect staan naar
je www.example.com site. Maar op die example.com machine heb je interne services (bijvoorbeeld een webmail)
draaien onder een URL zoals https://example.com/webmail.
Nu wil je de TLS security van je example.com machine testen. Dat gaat niet! Want omdat example.com meteen
redirect naar www.example.com gaan ze DIE machine testen, en je krijgt geen kans om https://example.com/webmail
te testen.
Door Anoniem: Ik vind het altijd wel jammer dat Internet.nl z'n stokpaardje IPv6 zo nodig moet promoten: Daardoor maakt je website nog geen onderdeel uit van het moderne internet. IPv6 staat (vrijwel volledig) los van al die goede beveiligingstests die er allemaal in staan. Minimaal zou je de optie willen geven om dit optioneel te includen
Het is geen stokpaardje, maar een officieel vastgestelde standaard/eis van het Forum Standaardisatie. Dat is oorspronkelijk ingericht voor (semi) overheid. Die hebben zich daar dan ook aan te houden (PTOLU). Voor anderen, zoals jou, is het mooi meegenomen dat je die site kunt gebruiken. Als jij dus vindt dat het risico voor het niet gebruiken van IPv6 laag genoeg is, dan houd jij je er gewoon niet aan. En legt het uit, als je een overheidsorganisatie bent.
Peter
10-12-2019, 13:49 door
Briolet
Door Anoniem: Mogelijk is het toch verstandig als grote mailpartijen eens gaan stoppen met mailen over onversleutelde verbindingen.
Als ik in het log van mijn mailserver kijk zie ik daar nooit onversleutelde verbindingen. Alleen TLS1.2 communicatie. Er is slechts één partij die hun mail nog via TLS 1.0 verstuurt. Als ik in mijn settings ook TLS 1.0 verbied, valt die niet terug op onversleutelt, maar vind ik alleen connectie errors in het log.
Het Platform Internetstandaarden stelt dat behoorlijk wat mailservers alleen oudere TLS-versies ondersteunen.
Of (zoals het artikel aangeeft) die nog altijd default de voorkeur geven aan "statische sleuteluitwisselingen" (TLS-RSA...-ciphers)Zo is dit bijv. het geval bij ZIGGO mail (zoals bijv. pop.ziggo.nl).
Deze mailserver geeft nog altijd de voorkeur aan TLS_RSA_WITH_AES_256_CBC_SHA256,
terwijl dit behoort tot de uit te faseren ciphers!!!
Ze zouden er bij ZIGGO goed aan doen om op hun mailservers als "Preferred cipher" eindelijk eens een sterk ECDHE-cipher te configuren...
Mailserver worden alleen getest op STARTTLS en niet op SSL/TLS.
Dus als je de versleuteling alleen op het laatste steunt, ben je volgens internet.nl
niet versleuteld en dus onveilig. Miskleun !!
Dus als je de versleuteling alleen op het laatste steunt, ben je volgens internet.nl
niet versleuteld en dus onveilig. Miskleun !!
Maar zelf heeft deze test site CSP problemen, volgens de CSP Evaluator.
Verder een A graad met 8 als veiligheidsscore hier:
https://webcookies.org/cookies/internet.nl/27789611?216476
Maar excessieve webserver info proliferatie gevonden voor: gunicorn/20.0.4 WSGI server
Event-gebaseerde HTTP/WSGI server (Python 3 bibliotheken),
wat weer de bovenstaande resultaten verklaart.
waarvan akte,
luntrus
frame-ancestors 'none'; (veilig)
default-src 'self' *.internet.nl; medium kwetsbaarheid
Evaluated CSP as seen by a browser supporting CSP Version 3
checkframe
checkframe-ancestors
check'none'
help_outlinedefault-src
help_outline'self'
'self' can be problematic if you host JSONP, Angular or user uploaded files.
help_outline*.internet.nl
No bypass found; make sure that this URL doesn't serve JSONP replies or Angular libraries.
help_outlineobject-src [missing]
Can you restrict object-src to 'none'? hoge kwetsbaarheid
default-src 'self' *.internet.nl; medium kwetsbaarheid
Evaluated CSP as seen by a browser supporting CSP Version 3
checkframe
checkframe-ancestors
check'none'
help_outlinedefault-src
help_outline'self'
'self' can be problematic if you host JSONP, Angular or user uploaded files.
help_outline*.internet.nl
No bypass found; make sure that this URL doesn't serve JSONP replies or Angular libraries.
help_outlineobject-src [missing]
Can you restrict object-src to 'none'? hoge kwetsbaarheid
Verder een A graad met 8 als veiligheidsscore hier:
https://webcookies.org/cookies/internet.nl/27789611?216476
Maar excessieve webserver info proliferatie gevonden voor: gunicorn/20.0.4 WSGI server
Event-gebaseerde HTTP/WSGI server (Python 3 bibliotheken),
wat weer de bovenstaande resultaten verklaart.
waarvan akte,
luntrus
Tsja, als je anderen zo de maat neemt, kun je een hoop kritiek terug verwachten.....
Door Anoniem: Mailserver worden alleen getest op STARTTLS en niet op SSL/TLS.
Dus als je de versleuteling alleen op het laatste steunt, ben je volgens internet.nl
niet versleuteld en dus onveilig. Miskleun !!
Dus als je de versleuteling alleen op het laatste steunt, ben je volgens internet.nl
niet versleuteld en dus onveilig. Miskleun !!
Zo te lezen is de scope alleen voor SMTP servers. Dus MTA's in het jargon - dat zijn de servers genoemd in het MX record voor een domain.
Daarop is alleen STARTTLS van toepassing.
Controleren of de uitgaande mailservers STARTTLS doen is van buiten niet mogelijk - je moet mail kunnen laten sturen door het domein. De uitgaande mailservers zouden andere mailservers kunnen zijn dan de inkomende die in de MX staan.
Ook voor deze servers is trouwens alleen STARTTLS van toepassing.
Alleen bij de 'smarthost' (MSA) - dus de "mailserver" die een eindgebruiker instelt als 'uitgaande mailserver' kan SSL/TLS van toepassing zijn, naast STARTTLS. Welke server smarthost is , is niet uit DNS af te leiden . Het hoeft absoluut niet dezelfde server te zijn die in de MX staat .
En de server waar de eindgebruiker de inkomende mail ophaalt (POP3,IMAP4, NFS,Exchange, ) staan ook niet in DNS - hier is zelfs discutabel of je die "mailserver" moet noemen.
Geen miskleun , het was je niet duidelijk dat het gaat om wat de MX support, en niet om wat de "mailserver die de eindgebruiker instelt" support.
Ook altijd even de fingerprints vergelijken met die in de browser aangegeven
luntrus
Secure browser connections can be intercepted and decrypted
by authorities who spoof the authentic site's certificate. But
the authentic site's fingerprint CANNOT be duplicated!
Domain Name Certificate Name EV Security Certificate's Authentic Fingerprint Click to view complete certificate chain
internet.nl internet.nl — 04:71:35:89:2F:32:89:69:DE:A5:3A:73:C4:2D:59:CE:E8:84:95:3C
Each site's authentic security certificate fingerprint (shown above) was just now obtained by GRC's servers from each target web
server. If your web browser sees a different fingerprint for the same certificate (carefully verify the Certificate Name is identical) that
forms strong evidence that something is intercepting your web browser's secure connections and is creating fraudulent site certificates.
Checken kan hier: https://www.grc.com/fingerprints.htm en dan in de browser bij het "slotje" kijken of dat het exact hetzelfde is. by authorities who spoof the authentic site's certificate. But
the authentic site's fingerprint CANNOT be duplicated!
Domain Name Certificate Name EV Security Certificate's Authentic Fingerprint Click to view complete certificate chain
internet.nl internet.nl — 04:71:35:89:2F:32:89:69:DE:A5:3A:73:C4:2D:59:CE:E8:84:95:3C
Each site's authentic security certificate fingerprint (shown above) was just now obtained by GRC's servers from each target web
server. If your web browser sees a different fingerprint for the same certificate (carefully verify the Certificate Name is identical) that
forms strong evidence that something is intercepting your web browser's secure connections and is creating fraudulent site certificates.
luntrus
Door Anoniem: Tsja, als je anderen zo de maat neemt, kun je een hoop kritiek terug verwachten.....
Wel bijzonder: ze helpen je gemakkelijk te checken of je website aan alle standaarden voldoet, standaarden die bij de overheid verplicht zijn. En dan krijgen ze hier publiek punten gegooid, terwijl ze ook gewoon netjes een bugbounty programma hebben waar je dat kunt melden.
Chapeau.
Deze site internet.nl is opgenomen in mijn lijstje scan sites. Goede actie daar.
Chapeau? Mogen opbouwende aanvullingen niet meer. Wie is daar nu niet blij mee?
Het is niet eens kritiek, het is aanvullende info verkregen via 3rd party cold recon additionele scans
via een extensie. Dit is info die een webbrowser extensie zo oplepelt voor iedereen.
Developers hebben dat soort extensies, zoals CSP Evaluator, nu eenmaal lopen in hun browsers
Security geinteresseerden ook. Meten is direct weten en scannen is direct kennen.
Ze kunnen iets met die info aanvangen of niet en het is ook nog van belang voor anderen,
die hierin wellicht zijn geinteresseerd.
Ik let nu eenmaal op de toepassing van best policies en security setting i.h.a.
Waarom doen we dat allemaal niet wat vaker.
Hoort u mij website en website toepassingen developers?
Wat is daar mis mee. Anders blijft de infrastructuur zo al tie is,
De algemene stand van zaken kan ons best wel eens zorgen baren.
#sockpuppet
Chapeau? Mogen opbouwende aanvullingen niet meer. Wie is daar nu niet blij mee?
Het is niet eens kritiek, het is aanvullende info verkregen via 3rd party cold recon additionele scans
via een extensie. Dit is info die een webbrowser extensie zo oplepelt voor iedereen.
Developers hebben dat soort extensies, zoals CSP Evaluator, nu eenmaal lopen in hun browsers
Security geinteresseerden ook. Meten is direct weten en scannen is direct kennen.
Ze kunnen iets met die info aanvangen of niet en het is ook nog van belang voor anderen,
die hierin wellicht zijn geinteresseerd.
Ik let nu eenmaal op de toepassing van best policies en security setting i.h.a.
Waarom doen we dat allemaal niet wat vaker.
Hoort u mij website en website toepassingen developers?
Wat is daar mis mee. Anders blijft de infrastructuur zo al tie is,
De algemene stand van zaken kan ons best wel eens zorgen baren.
#sockpuppet
Door Anoniem: Ook altijd even de fingerprints vergelijken met die in de browser aangegeven
Secure browser connections can be intercepted and decrypted
by authorities who spoof the authentic site's certificate. But
the authentic site's fingerprint CANNOT be duplicated!
Domain Name Certificate Name EV Security Certificate's Authentic Fingerprint Click to view complete certificate chain
internet.nl internet.nl — 04:71:35:89:2F:32:89:69:DE:A5:3A:73:C4:2D:59:CE:E8:84:95:3C
Each site's authentic security certificate fingerprint (shown above) was just now obtained by GRC's servers from each target web
server. If your web browser sees a different fingerprint for the same certificate (carefully verify the Certificate Name is identical) that
forms strong evidence that something is intercepting your web browser's secure connections and is creating fraudulent site certificates.
by authorities who spoof the authentic site's certificate. But
the authentic site's fingerprint CANNOT be duplicated!
Domain Name Certificate Name EV Security Certificate's Authentic Fingerprint Click to view complete certificate chain
internet.nl internet.nl — 04:71:35:89:2F:32:89:69:DE:A5:3A:73:C4:2D:59:CE:E8:84:95:3C
Each site's authentic security certificate fingerprint (shown above) was just now obtained by GRC's servers from each target web
server. If your web browser sees a different fingerprint for the same certificate (carefully verify the Certificate Name is identical) that
forms strong evidence that something is intercepting your web browser's secure connections and is creating fraudulent site certificates.
... or that something is intercepting the connections from GRC and is doing the same. You cannot know which of the two.
(en gezien de totaal waardeloze claims die GRC in het verleden al gemaakt heeft gaan we er maar niet van uit dat
bij hem alles klopt)
11-12-2019, 15:00 door
packetguy
Mindef.nl de krijgsmacht van nederland heeft nog steeds geen DANE geïmplementeerd terwijl ze nog 20 dagen hebben.
StartTLS is pas sinds een maand doorgevoerd en de cipher suites zijn niet meer voldoende volgens de richtlijnen van NCSC te testen via internet.nl
Ik heb ze maar weer gemaild..
StartTLS is pas sinds een maand doorgevoerd en de cipher suites zijn niet meer voldoende volgens de richtlijnen van NCSC te testen via internet.nl
Ik heb ze maar weer gemaild..
Door Anoniem:
Zo te lezen is de scope alleen voor SMTP servers. Dus MTA's in het jargon - dat zijn de servers genoemd in het MX record voor een domain.
Daarop is alleen STARTTLS van toepassing.
Dat is niet juist. Soms wordt ook ssl/tls gebruikt door uitgaande mailservers. Dus moeten ingaande servers daar ook geschikt voor zijn.Door Anoniem: Mailserver worden alleen getest op STARTTLS en niet op SSL/TLS.
Dus als je de versleuteling alleen op het laatste steunt, ben je volgens internet.nl
niet versleuteld en dus onveilig. Miskleun !!
Dus als je de versleuteling alleen op het laatste steunt, ben je volgens internet.nl
niet versleuteld en dus onveilig. Miskleun !!
Zo te lezen is de scope alleen voor SMTP servers. Dus MTA's in het jargon - dat zijn de servers genoemd in het MX record voor een domain.
Daarop is alleen STARTTLS van toepassing.
Door Anoniem:
Zo is dit bijv. het geval bij ZIGGO mail (zoals bijv. pop.ziggo.nl).
Deze mailserver geeft nog altijd de voorkeur aan TLS_RSA_WITH_AES_256_CBC_SHA256,
terwijl dit behoort tot de uit te faseren ciphers!!!
Maar misschien heeft Ziggo nog wel een heel hoop legacy clients draaien. Bijvoorbeeld XP, of oude android versies of verzin het wat voor een legacy linux systemen via IOT verbinding maken met de mail servers bij Ziggo.Het Platform Internetstandaarden stelt dat behoorlijk wat mailservers alleen oudere TLS-versies ondersteunen.
Of (zoals het artikel aangeeft) die nog altijd default de voorkeur geven aan "statische sleuteluitwisselingen" (TLS-RSA...-ciphers)Zo is dit bijv. het geval bij ZIGGO mail (zoals bijv. pop.ziggo.nl).
Deze mailserver geeft nog altijd de voorkeur aan TLS_RSA_WITH_AES_256_CBC_SHA256,
terwijl dit behoort tot de uit te faseren ciphers!!!
Ze zouden er bij ZIGGO goed aan doen om op hun mailservers als "Preferred cipher" eindelijk eens een sterk ECDHE-cipher te configuren...
Wat misschien ook een veel zwaardere CPU load gaat opleveren? We hebben het niet over een paar gebruikers.Door Anoniem:
Door Anoniem:
Zo is dit bijv. het geval bij ZIGGO mail (zoals bijv. pop.ziggo.nl).
Deze mailserver geeft nog altijd de voorkeur aan TLS_RSA_WITH_AES_256_CBC_SHA256,
terwijl dit behoort tot de uit te faseren ciphers!!!
Maar misschien heeft Ziggo nog wel een heel hoop legacy clients draaien. Bijvoorbeeld XP, of oude android versies of verzin het wat voor een legacy linux systemen via IOT verbinding maken met de mail servers bij Ziggo.Het Platform Internetstandaarden stelt dat behoorlijk wat mailservers alleen oudere TLS-versies ondersteunen.
Of (zoals het artikel aangeeft) die nog altijd default de voorkeur geven aan "statische sleuteluitwisselingen" (TLS-RSA...-ciphers)Zo is dit bijv. het geval bij ZIGGO mail (zoals bijv. pop.ziggo.nl).
Deze mailserver geeft nog altijd de voorkeur aan TLS_RSA_WITH_AES_256_CBC_SHA256,
terwijl dit behoort tot de uit te faseren ciphers!!!
Precies, als je dit eruit gooit kan oudere software niets meer. Je mag het ook achteraan de prioriteitlijst zetten. Ik vond het al heel wat om ueberhaupt STARTTLS als eis te stellen op een van de MX servers die ik beheer. Volgende stap zou moeten zijn dat elke server een geldig publiek CA certificaat gebruikt en niet een zelf gegeneerd exemplaar. Daar moet wat meer de nadruk op worden gelegd, ik zie dat zelden genoemd. Aan alleen een self-signed certicaat heb je niets bij een MitM aanval.
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.
