FBI hekelt softwareleveranciers over buffer overflows: onvergeeflijke fout
De FBI en het Amerikaanse cyberagentschap CISA hebben uitgehaald naar softwareleveranciers die in hun producten nog steeds buffer overflows hebben zitten. Dit zijn volgens de Amerikaanse overheidsdiensten 'onvergeeflijke fouten' die de nationale veiligheid van de VS in gevaar brengen en waar al twintig jaar allerlei oplossingen voor bestaan. Toch blijft er software op de markt komen met buffer overflows, wat in het ergste geval tot gecompromitteerde systemen kan leiden.
"Buffer overflow-kwetsbaarheden doen zich voor wanneer aanvallers informatie benaderen of schrijven naar het verkeerde deel van het computergeheugen, bijvoorbeeld buiten de geheugenbuffer", aldus de FBI en het CISA. In het ergste geval kan een aanvaller zo zijn eigen code op het systeem uitvoeren. De Amerikaanse overheidsdiensten stellen dat het gebruik van onveilige programmeer practices die tot buffer overflows kunnen leiden, met name het gebruik van 'memory unsafe' programmeertalen, een onacceptabel risico voor de nationale en economische veiligheid van de Verenigde Staten vormen.
In een vandaag verschenen 'Secure by Design Alert' roepen de FBI en het CISA softwareleveranciers op om bewezen mitigaties toe te passen om buffer overflows te voorkomen. Klanten moeten daarnaast veilige software eisen die over dergelijke mitigaties beschikken. In de waarschuwing geven de overheidsdiensten ook advies aan softwareleveranciers, zoals het gebruik van 'memory-safe' programmeertalen waar mogelijk, het grondig onderzoeken van de oorzaak van gevonden kwetsbaarheden en het uitvoeren van security-audits.
"De community van softwareontwikkelaars beschikt over twintig jaar aan uitgebreide kennis en effectieve oplossingen voor buffer overflows. Helaas blijven veel softwareleveranciers klanten aan producten met deze kwetsbaarheden blootstellen", aldus de FBI en het CISA (pdf).
Reacties (13)
12-02-2025, 17:00 door
Anoniem
Ik vraag me al langer af wanneer software leveranciers de verantwoordelijkheid niet meer kunnen afschuiven...
Mogelijk alleen bij open source omdat je als klant dan zelf onderzoek kan doen.
Mogelijk alleen bij open source omdat je als klant dan zelf onderzoek kan doen.
12-02-2025, 17:49 door
Anoniem
10 procent van alle programmeurs zijn goede programmeurs.
Helaas denkt 90 procent dat zij tot die 10 procent behoort.
Zie ook: Sturgeons's Law.
Helaas denkt 90 procent dat zij tot die 10 procent behoort.
Zie ook: Sturgeons's Law.
12-02-2025, 19:50 door
Wim ten Brink
Een buffer overflow komt in principe maar bij een paar programmeertalen voor. We praten dan over C, C++, Assembly en COBOL. (En mogelijk een paar andere talen met slechte compilers.) Er zijn al veel technieken ontwikkeld die dit kunnen voorkomen en sommige technieken zijn zelfs ingebouwd in diverse compilers. Daarnaast zijn virtuele machines steeds populairder aan het worden (Java, LLVM, .NET) die hier ook veel bescherming kunnen bieden.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
12-02-2025, 21:13 door
Anoniem
Door Wim ten Brink: Een buffer overflow komt in principe maar bij een paar programmeertalen voor. We praten dan over C, C++, Assembly en COBOL.
COBOL? Weet je het zeker?Ik moet zeggen dat ik niet bepaald bij ben in wat daar voor ontwikkelingen hebben plaatsgevonden, maar toen ik ooit COBOL-programmeur was in een mainframe-omgeving werkten dat met vaste veldlengtes en nagenoeg altijd vaste recordlengtes, had een programma een al bij compilatie vast ingedeelde "working storage" waar geen dynamische allocatie in de loop van de uitvoering van het programma aan te pas kwam, en de controle of je tabel-elementen buiten de bovengrens van een tabel benaderde was automatisch als je de betreffende compiler-optie gebruikte. Record-layouts die je definieerde werden op runtime over de IO-buffers gelegd door de COBOL-runtime, je had gewoon na het lezen die velden tot je beschikking. Er kon echt wel van alles misgaan als je aan het ontwikkelen en het testen was, maar buffer overflows zaten daar simpelweg niet bij, volgens mij heb ik pas kennis gemaakt met dat verschijnsel toen ik in andere talen leerde programmeren.
Maar mogelijk ben ik niet bij, is dat ouderwets COBOL en heeft men allerlei moderne mogelijkheden toegevoegd die de deur hebben open gezet voor buffer overflows. Hoe dan ook, al is er een shitload aan terechte kritiek die je kan hebben op COBOL, het verrast me dat buffer overflows daarbij genoemd worden.
12-02-2025, 21:50 door
Anoniem
Door Anoniem: 10 procent van alle programmeurs zijn goede programmeurs.
Helaas denkt 90 procent dat zij tot die 10 procent behoort.
Zie ook: Sturgeons's Law.
Helaas denkt 90 procent dat zij tot die 10 procent behoort.
Zie ook: Sturgeons's Law.
Dat is niet wat Sturgeon's Law zegt:
The Revelation
Ninety percent of everything is crud.
Corollary 1
The existence of immense quantities of trash in science fiction is admitted and it is regrettable; but it is no more unnatural than the existence of trash anywhere.
Corollary 2
The best science fiction is as good as the best fiction in any field.
https://en.wikipedia.org/wiki/Sturgeon%27s_law
(Theodore Sturgeon was een science fiction schrijver en recencent.)
12-02-2025, 22:07 door
Anoniem
De FBI en het Amerikaanse cyberagentschap CISA hebben uitgehaald naar softwareleveranciers die in hun producten nog steeds buffer overflows hebben zitten
SELinux kan een bufferoverloop nauwkeurig afhandelen maar beter is om een memory-safe programmeertaal te gebruiken maar dat is niet altijd mogelijk.
13-02-2025, 08:28 door
Anoniem
Door Wim ten Brink: Een buffer overflow komt in principe maar bij een paar programmeertalen voor. We praten dan over C, C++, Assembly en COBOL.
Vergeet daarbij niet dat de runtimes van heel veel andere programmeertalen in C of C++ geschreven zijn. Dus ook al kan je eigen programma er geen last van hebben, je kunt er wel door getroffen worden.
13-02-2025, 09:20 door
Anoniem
Door Wim ten Brink:
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Het probleem zit bij de consument... want die zijn niet bereid om meer te betalen voor programma's.
13-02-2025, 10:35 door
Anoniem
Door Anoniem:
Het probleem zit bij de consument... want die zijn niet bereid om meer te betalen voor programma's.
Het probleem is meestal gesloten software (te weinig ontwikkelcapaciteit) . Daar richten ze zich ook op.Door Wim ten Brink:
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Het probleem zit bij de consument... want die zijn niet bereid om meer te betalen voor programma's.
13-02-2025, 11:33 door
Anoniem
Door Wim ten Brink: Een buffer overflow komt in principe maar bij een paar programmeertalen voor. We praten dan over C, C++, Assembly en COBOL. (En mogelijk een paar andere talen met slechte compilers.) Er zijn al veel technieken ontwikkeld die dit kunnen voorkomen en sommige technieken zijn zelfs ingebouwd in diverse compilers. Daarnaast zijn virtuele machines steeds populairder aan het worden (Java, LLVM, .NET) die hier ook veel bescherming kunnen bieden.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Programmeur veegt programmeurs straatje schoon.
In jouw theorie zouden open source projecten - programmeurs zonder hijgende managers in hun nek dus geen buffer overflow fouten maken, want ze kunnen de tijd nemen om dat te voorkomen en heel erg perfecte code schrijven.
Oeps - ze maken dat soort fouten ook.
Btw - LLVM is geen virtuele machine (ondanks de historische naam), maar een (set van) compilers.
Java is een taal - die inderdaad vrijwel altijd op een JVM (Java virtual machine) draait en niet 'native' (.Net idem).
JVM (Java, Kotlin) is net wat beter om het VM aspect te benadrukken.
13-02-2025, 12:42 door
Anoniem
Door Anoniem:
Programmeur veegt programmeurs straatje schoon.
In jouw theorie zouden open source projecten - programmeurs zonder hijgende managers in hun nek dus geen buffer overflow fouten maken, want ze kunnen de tijd nemen om dat te voorkomen en heel erg perfecte code schrijven.
Oeps - ze maken dat soort fouten ook.
Btw - LLVM is geen virtuele machine (ondanks de historische naam), maar een (set van) compilers.
Java is een taal - die inderdaad vrijwel altijd op een JVM (Java virtual machine) draait en niet 'native' (.Net idem).
JVM (Java, Kotlin) is net wat beter om het VM aspect te benadrukken.
Door Wim ten Brink: Een buffer overflow komt in principe maar bij een paar programmeertalen voor. We praten dan over C, C++, Assembly en COBOL. (En mogelijk een paar andere talen met slechte compilers.) Er zijn al veel technieken ontwikkeld die dit kunnen voorkomen en sommige technieken zijn zelfs ingebouwd in diverse compilers. Daarnaast zijn virtuele machines steeds populairder aan het worden (Java, LLVM, .NET) die hier ook veel bescherming kunnen bieden.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Programmeur veegt programmeurs straatje schoon.
In jouw theorie zouden open source projecten - programmeurs zonder hijgende managers in hun nek dus geen buffer overflow fouten maken, want ze kunnen de tijd nemen om dat te voorkomen en heel erg perfecte code schrijven.
Oeps - ze maken dat soort fouten ook.
Btw - LLVM is geen virtuele machine (ondanks de historische naam), maar een (set van) compilers.
Java is een taal - die inderdaad vrijwel altijd op een JVM (Java virtual machine) draait en niet 'native' (.Net idem).
JVM (Java, Kotlin) is net wat beter om het VM aspect te benadrukken.
Given enough eyeballs, all bugs are shallow. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Dat zie je terug bij grote open source projecten. Het gebrek aan eyeballs is een vet probleem bij gesloten software, waar een technical feature belangrijker is dan secure by design.
14-02-2025, 11:43 door
Anoniem
Door Anoniem:
Given enough eyeballs, all bugs are shallow. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Dat zie je terug bij grote open source projecten. Het gebrek aan eyeballs is een vet probleem bij gesloten software, waar een technical feature belangrijker is dan secure by design.
Het is handig om naar het origineel te verwijzen, waar je die uitspraak in zijn context kan zien, het was een observatie van Eric S. Raymond over hoe gewerkt werd aan de Linux-kernel:Door Anoniem: In jouw theorie zouden open source projecten - programmeurs zonder hijgende managers in hun nek dus geen buffer overflow fouten maken, want ze kunnen de tijd nemen om dat te voorkomen en heel erg perfecte code schrijven.
Oeps - ze maken dat soort fouten ook.
Oeps - ze maken dat soort fouten ook.
Given enough eyeballs, all bugs are shallow. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Dat zie je terug bij grote open source projecten. Het gebrek aan eyeballs is een vet probleem bij gesloten software, waar een technical feature belangrijker is dan secure by design.
Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.''
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html (http, er is zo te zien geen geldig https-certificaat voor deze site)8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.''
De laatste zin die ik citeer is belangrijk: de "many eyeballs" garanderen niet dat bugs snel gevonden worden, ze vergroten de kans dat een eenmaal gevonden bug snel wordt opgelost, omdat, zoals de rest van het citaat uitlegt, de open werkwijze met veel actief betrokkenen de kans vergroot dat iemand die het snel snapt het onder ogen krijgt.
Het is alleen niet zo dat ieder open source-project dit goed doet. Ja, het helpt als het project groot is, natuurlijk. Maar ik ben ook wel eens een project tegengekomen met een flinke groep groep actieve deelnemers die meer enthousiast dan kundig leken te zijn. Ook zijn er essentiële open source-projecten waar maar een handjevol mensen naar omkijkt. En de software die Airbus maakt voor de besturing van vliegtuigen zal echt niet van de buffer overflows aan elkaar hangen, ook al is het closed source, die dingen blijven althans opmerkelijk vaak vliegen als dat de bedoeling is.
Open of closed source is een factor in hoe software ontwikkeld wordt, maar het is niet de enige factor en je mist een hoop als je het tot alleen dat reduceert, er zijn altijd meer factoren die meespelen.
16-02-2025, 23:48 door
Anoniem
Door Anoniem:
Given enough eyeballs, all bugs are shallow. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Dat zie je terug bij grote open source projecten. Het gebrek aan eyeballs is een vet probleem bij gesloten software, waar een technical feature belangrijker is dan secure by design.
Door Anoniem:
Programmeur veegt programmeurs straatje schoon.
In jouw theorie zouden open source projecten - programmeurs zonder hijgende managers in hun nek dus geen buffer overflow fouten maken, want ze kunnen de tijd nemen om dat te voorkomen en heel erg perfecte code schrijven.
Oeps - ze maken dat soort fouten ook.
Btw - LLVM is geen virtuele machine (ondanks de historische naam), maar een (set van) compilers.
Java is een taal - die inderdaad vrijwel altijd op een JVM (Java virtual machine) draait en niet 'native' (.Net idem).
JVM (Java, Kotlin) is net wat beter om het VM aspect te benadrukken.
Door Wim ten Brink: Een buffer overflow komt in principe maar bij een paar programmeertalen voor. We praten dan over C, C++, Assembly en COBOL. (En mogelijk een paar andere talen met slechte compilers.) Er zijn al veel technieken ontwikkeld die dit kunnen voorkomen en sommige technieken zijn zelfs ingebouwd in diverse compilers. Daarnaast zijn virtuele machines steeds populairder aan het worden (Java, LLVM, .NET) die hier ook veel bescherming kunnen bieden.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
-
Het probleem is echter dat betere en veiligere programma's ook meer tijd vragen om te ontwikkelen. Daaronder dus niet alleen het schrijven van de code, maar ook het testen en code analyses. En tijd is geld, he? Als het 4 uur extra kost op een project van 80 uur dan praten we over een prijsverhoging van 5%. Met een uurloon van 50 euro per uur is dat toch 250 euro extra.
Dus worden er keuzes gemaakt door management. Ze zetten er gewoon goedkopere ontwikkelaars op, bijvoorbeeld door outsourcing. Of stel minder hoge eisen en riskeer dus dit soort problemen.
Het probleem zit dan ook niet bij de programmeurs maar bij management.
Programmeur veegt programmeurs straatje schoon.
In jouw theorie zouden open source projecten - programmeurs zonder hijgende managers in hun nek dus geen buffer overflow fouten maken, want ze kunnen de tijd nemen om dat te voorkomen en heel erg perfecte code schrijven.
Oeps - ze maken dat soort fouten ook.
Btw - LLVM is geen virtuele machine (ondanks de historische naam), maar een (set van) compilers.
Java is een taal - die inderdaad vrijwel altijd op een JVM (Java virtual machine) draait en niet 'native' (.Net idem).
JVM (Java, Kotlin) is net wat beter om het VM aspect te benadrukken.
Given enough eyeballs, all bugs are shallow. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Dat zie je terug bij grote open source projecten. Het gebrek aan eyeballs is een vet probleem bij gesloten software, waar een technical feature belangrijker is dan secure by design.
Ik denk dat je eens wat breder moet kijken dat de handvol super projecten zoals de Linux kernel, Apache webserver e.a.
Github (en een willekeurige linux distro) zit stampvol projecten waar maar een handvol (of enkeling) mensen aan werken.
xz werd toevallig bekend vanwege de introductie van een backdoor - dat waren 4 eyeballs, 2 burned out, 2 malicious, ongeveer. Het is helaas niet zo dat dat een uitzondering is van "kleine component met kleine community die in veel distro's zit" .
Verder - Wim stelde dat bugs kwamen omdat "managers" de verkeerde priorititeiten stellen.
Dan , groot of klein - volgens die theorie zouden er "geen" buffer overflows in hobby (open source) projecten zitten omdat daar de programmeur niet opgejaagd wordt of "gedwongen" wordt om nieuwe features prioriteit te geven .
Hooguit gaat ontwikkeling langzamer omdat die programmeurs zo zorgvuldig en perfect werken.
Wel - Niet Dus .
Pak gewoon de eerste 500 van de tig duizend packages in een linux distro, neem de code, en vertel eens waarom dat "secure by design" is .
En blader dan ook eens door de contributors , en kijk eens hoeveel dat er zijn .
Linus benoemt dat nog wel eens op kernel summits - dat tot zijn geluk de kernel community _wel_ groot en levendig is, en dat dat niet opgaat voor heel veel andere open source projecten.
Dat is het leuke van open source - je hoeft het niet te geloven of te speculeren, je kunt het bekijken, 'how the sausage is made' .
Ik zal niet zeggen dat het slecht (of slechter ) is , maar ik wordt een beetje moe van alle heiligverklaring, en nog meer van programmeurs die het straatje van hun beroepsgroep te schoon vegen.
Als je programmeurs zonder management laat werken komt er ook geen perfectie uit - en dus is het nogal onterecht om alle imperfectie te wijten aan "hullie stropdas management"
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Bescherm data, waarborg privacy!
Als Information Security & Privacy Officer bij Kader Group zorg jij voor digitale veiligheid en privacybescherming. Jij houdt bedrijven compliant en weerbaar.
- Salaris tot €6.000
- Leaseauto & hybride werken
- Groei als security-expert
Word onderdeel van ons team.
Solliciteer nu!
SOC Lead
Directie Informatievoorziening & Inkoop
Als SOC Lead ben je de inhoudelijke en technische motor van ons team. Je werkt actief mee met de security analisten en bent hun sparringspartner en coach. Samen met het team zorg je ervoor dat detectie, analyse en response op hoog niveau worden uit-gevoerd en verder worden ontwikkeld.
Hoofd Veiligheid
Dienst Justitiële Inrichtingen
Als Hoofd Veiligheid binnen de PI Leeuw-arden ligt de verantwoordelijkheid voor het waarborgen en verbeteren van het organi-satieonderdeel Veiligheid in jouw handen. Een unieke uitdaging met een grote impact. Die kans laat jij je niet ontnemen!
Cybersecurity Trainer / Full Stack Developer
bij Certified Secure
Ben je toe aan een nieuwe nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.