'45-jaar oude internetprotocollen moeten op de schop'
De 45-jaar oude protocollen waar het internet gebruik van maakt zijn nooit ontwikkeld om met cyberaanvallen om te gaan en moeten op de schop. Daarvoor pleitte Verizon-topman Marcus Sachs deze week tijdens de AusCERT Conferentie in het Australische Gold Coast.
Sachs wees naar de internetprotocollen die nog van het ARPANET uit 1969 dateren. De onderzoekers die de protocollen ontwikkelden hebben nooit voorgesteld dat ze op een gegeven moment het doelwit van online aanvallers zouden worden. "ARPANET is verdwenen, maar het internet is er nog. Kunnen we de simulatie herprogrammeren?", zo stelde Sachs de vraag.
De onderzoekers die tientallen jaren geleden de regels opstelden zorgden ervoor dat het "Huis" in academische scenario's altijd zou winnen. Tegenwoordig zijn de spelers in het spel echter veranderd, terwijl de regels hetzelfde zijn gebleven. "De dealers zijn niet meer het personeel van het Huis en de gokkers aan de tafel zijn niet meer de toevallige voorbijgangers van de straat." Het Huis staat dan ook op het punt om failliet te gaan, aldus de Verizon-topman.
Hij merkte op dat er honderden internetprotocollen zijn ontwikkeld, maar dat er slechts twee dominante protocollen zijn: TCP en UDP. "We hebben dit fantastische ding gebouwd genaamd het internet en we gebruiken het voor slechts twee primaire protocollen, wat zonde." Dit heeft volgens Sachs de weg voor cybercriminelen geopend die minder bekende protocollen voor hun doeleinden inzetten.
"Kunnen we het internet herprogrammeren? Het kost misschien nog eens 40 jaar om dit te doen. We kunnen de regels veranderen en een nieuw internet bouwen of misschien leven met de regels die er zijn en creatieve manieren vinden om de regels te gebruiken die we hebben." Sachs voegde toe dat hij niet hoopt dat mensen over 40 jaar nog steeds de TCP- en UDP-protcollen nodig hebben om het web te gebruiken, zo meldt Computerworld.
Reacties (24)
17-05-2014, 10:33 door
vigilance
interesting
Nieuw ontwikkelde protocollen zijn niet echt niet veel veiliger, dus ik weet niet wat Sachs zich hierbij voorstelt. Het is bijna zeker dat "veilige" transportprotocollen, d.w.z. verplaatsen van de veiligheidslaag naar beneden de zaak een stuk trager maakt.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Implementatie lijkt mij in dit geval belangrijker dan het wiel opnieuw uit proberen te vinden.
40 jaar? waar heeft deze meneer van Verizon het over??
Want binnenkort is er toch al een nieuw internet met IPv6 icm een biometric internet-login voor iedere gebruiker.
Want binnenkort is er toch al een nieuw internet met IPv6 icm een biometric internet-login voor iedere gebruiker.
Als we dan kom gelijk even oude programmeertalen als C en C++ weggooien, evenals talen die hiermee geimpementeerd worden zoals Perl en Java, dat zou ook al helpen.
17-05-2014, 18:30 door
Skizmo
Door Anoniem: Als we dan kom gelijk even oude programmeertalen als C en C++ weggooien, evenals talen die hiermee geimpementeerd worden zoals Perl en Java, dat zou ook al helpen.
Dit is dus echt zo'n achtelijke uitspraak. Alle 'hogere' talen danken hun bestaansrecht aan C/C++. De programmeer wereld is niks zonder C/C++.
17-05-2014, 20:12 door
AapNootMies
Door Anoniem:
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Misschien waar; maar UDP (want stateless protocol) is niet bepaald een prettig idee om als primair protocol te gaan gebruiken...
Door Skizmo:
Door Anoniem: Als we dan kom gelijk even oude programmeertalen als C en C++ weggooien, evenals talen die hiermee geimpementeerd worden zoals Perl en Java, dat zou ook al helpen.
Dit is dus echt zo'n achtelijke uitspraak. Alle 'hogere' talen danken hun bestaansrecht aan C/C++. De programmeer wereld is niks zonder C/C++.Dat is juist het probleem. Dankzij C zijn ook Java ed. kwetsbaar. We kunnen wel weer veel software in C gaan schrijven om nieuwe protocollen te maken, maar dan komen we dezelfde issues weer tegen zoals buffer overflows ed. De IT moet echt een paradigma-shift maken om fundamentele stappen te nemen in cyberveilige software. Net zoals patchen, hoe primitief kun je het hebben en waarom is er in 20 jaar nog niemand met iets beters begonnen. Nee, we huren wel wat 'experts' in en kopen een kudde firewalls, dan komt het goed...
Ik hoor de aannemer van een wrak huis, wiens bouwvakkers de helft van de schroeven weglaten, die geen opzichter heeft die controles doet, de schuld geven aan "schroeven die sinds de Romeinse tijd niet veranderd zijn" .
Door Anoniem: Nieuw ontwikkelde protocollen zijn niet echt niet veel veiliger, dus ik weet niet wat Sachs zich hierbij voorstelt. Het is bijna zeker dat "veilige" transportprotocollen, d.w.z. verplaatsen van de veiligheidslaag naar beneden de zaak een stuk trager maakt.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Waar haal je dat nou weer vandaan ?
De redenen om in sommige toepassingen UDP te gebruiken hebben niets te maken met 'throughput van TCP is traag'.
Door Anoniem:TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Ik ken Gbe zelf niet en heb het verhaal ook nog nooit gehoord over TCP te traag van bijv. mensen met 900Mbit up/down glasvezel, maar heeft het niet meer met de bandbreedte te maken hoe snel iets is dan dat het transport laag dat begrenst? Uit nieuwsgierigheid ben ik benieuwd of er meer info over is te geven, kan dat niet direct vinden, want het is een interessant onderwerp.
18-05-2014, 00:27 door
[Account Verwijderd]
-
Bijgewerkt: 18-05-2014, 00:28
[Verwijderd]
Door Anoniem:
Waar haal je dat nou weer vandaan ?
De redenen om in sommige toepassingen UDP te gebruiken hebben niets te maken met 'throughput van TCP is traag'.
Door Anoniem: Nieuw ontwikkelde protocollen zijn niet echt niet veel veiliger, dus ik weet niet wat Sachs zich hierbij voorstelt. Het is bijna zeker dat "veilige" transportprotocollen, d.w.z. verplaatsen van de veiligheidslaag naar beneden de zaak een stuk trager maakt.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Waar haal je dat nou weer vandaan ?
De redenen om in sommige toepassingen UDP te gebruiken hebben niets te maken met 'throughput van TCP is traag'.
Professionele kennis. Je draait de stelling om en het heeft dus helemaal niets te maken met wat ik schreef.
Er zijn overigens meerdere goede redenen om UDP te gebruiken in de toepassing die ik noemde. Zoek eens op: UDT.
Door Joey van Hummel:
Ik hoop dat dit sarcastisch bedoeld is. Ten eerste zie ik de directe relevantie tot het bericht niet; die heb je niet echt laten blijken.
Ten tweede is er niks mis met C/C++. Ze zijn niet inherent insecure/langzaam. Het zijn gewoon talen waar je moet uitkijken/weten wat je doet. Dat betekent nog niet dat we de talen moeten schrappen. Eerder de programmers die maar wat doen in kritieke applicaties.
Door Anoniem: Als we dan kom gelijk even oude programmeertalen als C en C++ weggooien, evenals talen die hiermee geimpementeerd worden zoals Perl en Java, dat zou ook al helpen.
Letterlijk: wat?Ik hoop dat dit sarcastisch bedoeld is. Ten eerste zie ik de directe relevantie tot het bericht niet; die heb je niet echt laten blijken.
Ten tweede is er niks mis met C/C++. Ze zijn niet inherent insecure/langzaam. Het zijn gewoon talen waar je moet uitkijken/weten wat je doet. Dat betekent nog niet dat we de talen moeten schrappen. Eerder de programmers die maar wat doen in kritieke applicaties.
Tja, uitkijken en weten wat je doet... Dat is nu juist het probleem, daar gaat het fout. Dat wil je toch niet met de hand en reviews en procedures goed krijgen, automatisering is er om ons te helpen en werk uit handen te nemen... Een programmeertaal waarin de zaken goed geregeld zijn, zodat het by design goed is, die hebben we nodig!
Door Anoniem: Ik hoor de aannemer van een wrak huis, wiens bouwvakkers de helft van de schroeven weglaten, die geen opzichter heeft die controles doet, de schuld geven aan "schroeven die sinds de Romeinse tijd niet veranderd zijn" .
Ik proef hier een gebrek een historisch besef. De Romeinen kenden geen schroeven. En al zouden ze die wel kennen, dan klopt de vergelijking niet. Als jij een opzichter nodig hebt (= reviewprocedure) vanwege zwakke schroeven, dan zou ik iets aan de oorzaak van het probleem doen, bv. betere schroeven ontwerpen, of een huis zo kunnen maken dat je geen schroef meer nodig hebt. Scheelt ook een opzichter (= ik snap dat je denkt aan je eigen baan als er geen programmeerfouten meer gemaakt worden)
Door Anoniem:
Ik ken Gbe zelf niet en heb het verhaal ook nog nooit gehoord over TCP te traag van bijv. mensen met 900Mbit up/down glasvezel, maar heeft het niet meer met de bandbreedte te maken hoe snel iets is dan dat het transport laag dat begrenst? Uit nieuwsgierigheid ben ik benieuwd of er meer info over is te geven, kan dat niet direct vinden, want het is een interessant onderwerp.
Door Anoniem:TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Ik ken Gbe zelf niet en heb het verhaal ook nog nooit gehoord over TCP te traag van bijv. mensen met 900Mbit up/down glasvezel, maar heeft het niet meer met de bandbreedte te maken hoe snel iets is dan dat het transport laag dat begrenst? Uit nieuwsgierigheid ben ik benieuwd of er meer info over is te geven, kan dat niet direct vinden, want het is een interessant onderwerp.
Het probleem is de overhead die TCP heeft en hoe (in)efficient netwerkkwaliteitproblemen worden opgelost. Voor het transporteren van grote hoeveelheden data heeft dat invloed.
Gbe is gigabit ethernet, het gaat hier over 10 Gbe. Als je de lijn volledig wil vullen dan is UDP daarvoor de meest gebruikte methode. Het heeft allerlei voordelen, maar dat gaat te ver off topic. Een toepassing is UDR die het UDT applicatie niveau protocol gebruikt.
Beetje vreemd advies aangezien er al meer dan voldoende manieren zijn om de zaak te beveiligen. Het grootste probleem is de immer toenemende complexiteit, de miljoenen regels code, de uitzonderingen, de steeds grotere gelaagdheid, de tijd en energie die het kost de zaak goed en veilig te configureren en bij te houden (firmware die bijv. ingestelde settings ongezien ongedaan maakt).
Het vergt vandaag zeer veel kennis, kunde en zeer veel tijd alles bij te houden, te begrijpen en alles nog een beetje bij te werken. Het is voor velen te onoverzichtelijk geworden, te gelaagd en te complex.
Een essentieel pakket dat 'out of the box' op alle niveau's superveilig is (en ook blijft) en eenvoudig te beheren valt zou al heleboel helpen. Of daarvoor nieuwe programmeertalen nodig zijn, betwijfel ik. Misschien eerder een andere werkwijze, meer tijd en minder gefocused op 'feature-ietes' en een ander management.
Een bedrijf dat zo iets maakt en op de markt brengt, maakt vandaag de dag wel een kans denk ik.
Het vergt vandaag zeer veel kennis, kunde en zeer veel tijd alles bij te houden, te begrijpen en alles nog een beetje bij te werken. Het is voor velen te onoverzichtelijk geworden, te gelaagd en te complex.
Een essentieel pakket dat 'out of the box' op alle niveau's superveilig is (en ook blijft) en eenvoudig te beheren valt zou al heleboel helpen. Of daarvoor nieuwe programmeertalen nodig zijn, betwijfel ik. Misschien eerder een andere werkwijze, meer tijd en minder gefocused op 'feature-ietes' en een ander management.
Een bedrijf dat zo iets maakt en op de markt brengt, maakt vandaag de dag wel een kans denk ik.
Die hele beeldspraak over 'Het Huis en de spelers' slaat echt nergens op ... sowies word ik er niet vrolijk van als een (Verizon-) topman alliteraties met gokspelen maakt; gokt hij ook met klantbelangen; heeft hij een verslaving waarvan we zouden moeten weten ? Geen slimme associatie m.i....
Daarnaast had meneer beter over DHCP, DNS, SMTP, FTP en andere nog in-onbeveiligde-variant te gebruiken protocollen kunnen beginnen; die L7 protocollen zijn stukken makkelijker te dichten (en dat blijkt al bijna onmogelijk) dan L2/L3 protocollen ...
Daarnaast had meneer beter over DHCP, DNS, SMTP, FTP en andere nog in-onbeveiligde-variant te gebruiken protocollen kunnen beginnen; die L7 protocollen zijn stukken makkelijker te dichten (en dat blijkt al bijna onmogelijk) dan L2/L3 protocollen ...
Door Anoniem:
Professionele kennis. Je draait de stelling om en het heeft dus helemaal niets te maken met wat ik schreef.
Er zijn overigens meerdere goede redenen om UDP te gebruiken in de toepassing die ik noemde. Zoek eens op: UDT.
Door Anoniem:
Waar haal je dat nou weer vandaan ?
De redenen om in sommige toepassingen UDP te gebruiken hebben niets te maken met 'throughput van TCP is traag'.
Door Anoniem: Nieuw ontwikkelde protocollen zijn niet echt niet veel veiliger, dus ik weet niet wat Sachs zich hierbij voorstelt. Het is bijna zeker dat "veilige" transportprotocollen, d.w.z. verplaatsen van de veiligheidslaag naar beneden de zaak een stuk trager maakt.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
TCP is al traag, in de toekomst zullen we naar UDP gaan om de snelheid aan de dan geldende eisen te kunnen matchen. Bij 10 Gbe heb je al UDP nodig het behalen van de maximum snelheid.
Waar haal je dat nou weer vandaan ?
De redenen om in sommige toepassingen UDP te gebruiken hebben niets te maken met 'throughput van TCP is traag'.
Professionele kennis. Je draait de stelling om en het heeft dus helemaal niets te maken met wat ik schreef.
Er zijn overigens meerdere goede redenen om UDP te gebruiken in de toepassing die ik noemde. Zoek eens op: UDT.
Je noemde helemaal geen toepassing. Je stelde zonder enige qualificatie dat 'UDP nodig is voor het halen van de maximum snelheid op 10GE' .
Zoals je wellicht weet kan een single-flow IPv6 (!) TCP sessie 9.08 Gbps throughput doen over een WAN circuit met een RTT van 500 msec, en deed dat al in 2008 .
Ik heb gezocht op UDT, en ik vond een hoop boeiende netwerk research maar niks wat lijkt op jouw stelling 'TCP is te traag' of 'naar UDP gaan om snelheid te matchen aan geldende eisen' .
Een van de UDT papers stelt inderdaad wat ik vermoedde, namelijk het nut van een userland applicatie waarin congestion control algorithmes en parameters makkelijk instelbaar zijn . Voor het doen van netwerk research is dat inderdaad best handig.
Maar dat is een heel eind weg van 'TCP is al traag' - geloof mijn professionele kennis maar. Je zult echt je statements meer moeten onderbouwen.
Door Anoniem:
Ik proef hier een gebrek een historisch besef. De Romeinen kenden geen schroeven. En al zouden ze die wel kennen, dan klopt de vergelijking niet. Als jij een opzichter nodig hebt (= reviewprocedure) vanwege zwakke schroeven, dan zou ik iets aan de oorzaak van het probleem doen, bv. betere schroeven ontwerpen, of een huis zo kunnen maken dat je geen schroef meer nodig hebt. Scheelt ook een opzichter (= ik snap dat je denkt aan je eigen baan als er geen programmeerfouten meer gemaakt worden)
Door Anoniem: Ik hoor de aannemer van een wrak huis, wiens bouwvakkers de helft van de schroeven weglaten, die geen opzichter heeft die controles doet, de schuld geven aan "schroeven die sinds de Romeinse tijd niet veranderd zijn" .
Ik proef hier een gebrek een historisch besef. De Romeinen kenden geen schroeven. En al zouden ze die wel kennen, dan klopt de vergelijking niet. Als jij een opzichter nodig hebt (= reviewprocedure) vanwege zwakke schroeven, dan zou ik iets aan de oorzaak van het probleem doen, bv. betere schroeven ontwerpen, of een huis zo kunnen maken dat je geen schroef meer nodig hebt. Scheelt ook een opzichter (= ik snap dat je denkt aan je eigen baan als er geen programmeerfouten meer gemaakt worden)
Ok, niet de Romeinen inderdaad, schroeven dateren uit de Middeleeuwen.
Waar ik op doel is dat wat er misgaat in security feitelijk altijd operationele fouten zijn (= de helft van de schroeven er niet in draaien) , gecombineerd met implementatie fouten (software bugs , laten we zeggen schroeven op de verkeerde plaats.)
De opzichter is er om te kijken of alle schroeven er wel in gedraaid worden, ook als het vrijdagmiddag is en de jongens snel naar huis willen.
Dat soort procedures gaat letterlijk zo bij luchtvaart onderhoud. De gevallen waarin het proces faalde komen langs bij 'aircrash investigations' , en daar zaten letterlijk gevallen bij waarbij de helft van de schroeven vergeten was, of net-niet-passende schroeven 'op het oog' uit het bakje gehaald waren. (BA vlucht 5390 , fwiw)
De baas van een telco is eindverantwoordelijk voor operationele zaken, en deels voor software bugs (websites die in-house ontwikkeld worden). En kijkend naar de security breaches die gebeuren is wijzen naar 'andere internet protocollen' een heel arrogante keuze. Splinter & balk.
Ik heb overigens geen zorgen over werk, ook niet als programma's opeens foutloos zouden worden.
Eigenlijk komt het erop neer dat TCP en familie, Ethernet, en OS'en allen gebaseerd zijn op ideeen en technologieen uit de jaren 70, ook wel bekend als 'vrijheid/blijheid' en 'heren lezen elkaars post niet'. Zo is dus Arpanet opgezet, systeembeheerders van universiteiten die elkaar kenden en een UUCP link opzetten om email door te sturen, met wederzijds vertrouwen. Toen kwam allerlei ander volk op internet en begon het gedoe. Je kunt geen systemen hebben die alles toestaan en die laten gebruiken door luitjes die alles misbruiken. Sindsdien is aan alles bult na bult toegevoegd om de initieel ontbreekde secruitydesignflaws weer toe te voegen, en 30 jaar later zijn we nog steeds niet klaar. Wat hebben we geleerd, wetende dat Ipv6 en Android dik 20 jaar na het eerste virus op de markt gekomen zijn en vanad dag 1 al zo lek zijn als een mandje? He-le-maal niets blijkbaar,
Door Anoniem:Er zijn overigens meerdere goede redenen om UDP te gebruiken in de toepassing die ik noemde. Zoek eens op: UDT.
Er zijn ook perfecte redenen om geen UDP te gebruiken. Zoek eens op: DDoS i.c.m. open resolver, Chargen, SNMP en/of NTP
Peter
De spelregels die toen, tijdens de ontwikkeling van ARPAnet zijn afgesproken zijn veranderd en het is een goede zaak dat daar nu weer eens kritisch naar wordt gekeken. En achteraf is het allemaal zo makkelijk om kritiek te leveren, maar probeer je eens in te leven in de periode waar we over praten, 1969, volgens mij waren sommige die hier posten nog niet eens geboren ;-)
Het was een chaos van netwerken en protocollen die met de meest onmogelijke technieken weer aan elkaar moesten worden geknoopt. In dat licht was IP een fantastische uitkomst en dat nu achteraf we een aantal dingen anders hadden moeten doen, tja is dat niet meestal zo - Voortschrijdend inzicht, laten we het daar maar op houden.
En wat betreft IPv6, daar had men veel meer uit kunnen halen als alleen meer adressen. Ik kan me nog herinneren dat er encryptie onderdeel van de stack zou zijn ...... Nu zie je daar niets meer van terug
Wanneer start de volgende IPng task force?
Het was een chaos van netwerken en protocollen die met de meest onmogelijke technieken weer aan elkaar moesten worden geknoopt. In dat licht was IP een fantastische uitkomst en dat nu achteraf we een aantal dingen anders hadden moeten doen, tja is dat niet meestal zo - Voortschrijdend inzicht, laten we het daar maar op houden.
En wat betreft IPv6, daar had men veel meer uit kunnen halen als alleen meer adressen. Ik kan me nog herinneren dat er encryptie onderdeel van de stack zou zijn ...... Nu zie je daar niets meer van terug
Wanneer start de volgende IPng task force?
19-05-2014, 15:28 door
rsterenb
Door Anoniem:Tja, uitkijken en weten wat je doet... Dat is nu juist het probleem, daar gaat het fout. Dat wil je toch niet met de hand en reviews en procedures goed krijgen, automatisering is er om ons te helpen en werk uit handen te nemen... Een programmeertaal waarin de zaken goed geregeld zijn, zodat het by design goed is, die hebben we nodig!
Oke, dus je wil een nieuwe programmeertaal. Waar had je bedacht die geweldige nieuwe taal in te schrijven? Assembly? Want kennelijk mag dat van jou niet in C/C++ of een andere taal die mbv C/C++ is geschreven. En van de talen die geschikt zijn om een andere programmeertaal mee te schrijven zijn dat er nogal wat hoor...
Reageren
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?