Oracle Solaris-rootkit gebruikt voor fraude met geldautomaten
Criminelen zijn erin geslaagd om Oracle Solaris-servers van banken met een rootkit te infecteren die vervolgens fraude met geldautomaten mogelijk maakte. Dat meldt securitybedrijf Mandiant in een analyse. Hoeveel geld erbij de aanvallen is buitgemaakt is onbekend.
De rootkit wordt Caketap genoemd en is een "kernel module rootkit" voor Oracle Solaris. Caketap kan netwerkverbindingen, processen en bestanden verbergen en is op de ATM switch server van banken aangetroffen. Deze server regelt het verkeer tussen de bank en de geldautomaat. De rootkit werd gebruikt voor ongeautoriseerde transacties door frauduleuze bankkaarten.
Wanneer een bankklant met zijn betaalkaart geld bij een geldautomaat opneemt, wordt er een bericht tussen de automaat en bankserver uitgewisseld. Zo worden de pincode en betaalkaart van de klant geverifieerd. In het geval van een legitieme klant slaat Caketap deze ATM-pinverificatie op. Wanneer de rootkit ziet dat er met een frauduleuze betaalkaart wordt gepind, speelt het de eerder opgenomen pinverificatie van de legitieme klant af, zodat de frauduleuze betaalkaart wordt geaccepteerd.
Daarnaast manipuleert de rootkit ook berichten bedoeld voor de Payment Hardware Security Module (HSM) van de server. Caketap wijzigt de mode van verschillende uitgaande berichten om zo de verificatie van de betaalkaart uit te schakelen. Hierdoor kan de HSM de betaalkaart niet verifiëren en genereert bij de frauduleuze betaalkaart een geldige respons. Hierdoor zal de geldautomaat de frauduleuze bankkaart accepteren waarna criminelen er geld mee kunnen opnemen.
Volgens Mandiant heeft een groep criminelen, aangeduid als UNC2891, Caketap ingezet als onderdeel van een grotere operatie waarbij ongeautoriseerde geldopnames bij geldautomaten van verschillende banken werden uitgevoerd. Hoe de groep toegang tot de bankservers weet te krijgen is onbekend.
Reacties (22)
"make extensive use of the Pluggable Authentication Module (PAM) based backdoor we track as SLAPSTICK to aid with credential harvesting, and to provide backdoor access to compromised machines in victim networks."
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
18-03-2022, 13:24 door
gradje71
Interessant. Nog nooit eerder van gehoord.
Door Anoniem: vraag me af of dit ook van toepassing is open Opensolaris/Illumos
We weten niet wat "dit" is. Er is een server gecompromitteerd (hoe weten we niet) en deze server is gebruikt om login gegevens en wachtwoorden te verzamelen. Daar was (tenminste) root toegang voor nodig. Deze gegevens leidde weer naar root toegang tot andere systemen in het netwerk.
Clusterfuck zeg maar.
Maar het mag duidelijk zijn dat als je tenminste root toegang hebt dat je dan kernel modules kunt laden en dat je dat PAM kunt manipuleren (wachtwoorden onderscheppen als je die gebruikt).
Mijn advies is: blokkeer tenminste wachtwoord gebaseerde logins op afstand (bijv. ssh). Gebruik in plaats daarvan "PKI". Oh, en zorg dat jouw systemen netjes zijn bijgewerkt.
Door Anoniem: "make extensive use of the Pluggable Authentication Module (PAM) based backdoor we track as SLAPSTICK to aid with credential harvesting, and to provide backdoor access to compromised machines in victim networks."
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
ha ha ha funny hoor... als admin van een machine met veel gebruikers heb ik zo toegang tot al die SSH sleutels van die gebruikers en dus ook meteen toegang tot al die machines waar ze password-less SSH opgezet hebben. Tja, niet iedere gebruiker is zo netjes en clever om de SSH sleutels van een password te voorzien. Server side kun je dat ook niet afdwingen.
Nog funnier dan; als je een password op de SSH key zet, dan is al het gemak weer van die password-less SSH login foetsie en dan gaan heel wat ansible mensen hard aan de piepel :).
Het komt er dus op neer dat je server side of met een 2FA aan de slag moet waarbij er het liefst geen shared secret voorheen heeft moetne uitgewisseld zijn tussen de betreffende client en server (dus dingen zoals google-authenticator en TOTPs alleen via een yubikey oid), danwel je hebt [daarbij] een fatsoenlijk password quality beleid dat rekening houdt met menselijk gedrag (accepteer lange passwords die niet veel te complex zijn voor mensen met allerlij rare tekentjes: i.e. de wel bekende "correct horse battery staple" : https://xkcd.com/936/ ).
Secrutiy betreft mensen, je moet gedrag van mensen in je beschouwingen mee nemen!
Secrutiy betreft mensen, je moet gedrag van mensen in je beschouwingen mee nemen!
Goed punt
Server side kun je dat ook niet afdwingen
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Door Anoniem:
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Server side kun je dat ook niet afdwingen
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Wat is daar mee wil zeggen is dat een admin, naar mijn mening, verantwoordelijkheid draagt voor zijn systeem. Behoorlijk wat admins zijn pro-actief en scannen de key's van hun gebruikers voor kwetsbaarheden (zoek maar eens op)
Geen idee bij welke bank en in welk land deze vermeende kwetsbaarheid speelde. Voor onderstaande off-topic discussie waarschijnlijk ook volstrekt irrelevant. Maar goed.
Door Anoniem:
ha ha ha funny hoor... als admin van een machine met veel gebruikers heb ik zo toegang tot al die SSH sleutels van die gebruikers en dus ook meteen toegang tot al die machines waar ze password-less SSH opgezet hebben. Tja, niet iedere gebruiker is zo netjes en clever om de SSH sleutels van een password te voorzien. Server side kun je dat ook niet afdwingen.!
Wel kan men de autorisatie van de SSH public key intrekken als zou blijken dat een gebruiker zich niet aan de beveiligingsvoorschriften houdt. Technisch afdwingen, niet persé, met procedureel afdekken kom je ook een eind. Premisse is dat de "gebruikers" binnen dezelfde organisatie vallen, althans aan dezelfde voorschriften kunnen worden opgelegd.Door Anoniem: "make extensive use of the Pluggable Authentication Module (PAM) based backdoor we track as SLAPSTICK to aid with credential harvesting, and to provide backdoor access to compromised machines in victim networks."
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
ha ha ha funny hoor... als admin van een machine met veel gebruikers heb ik zo toegang tot al die SSH sleutels van die gebruikers en dus ook meteen toegang tot al die machines waar ze password-less SSH opgezet hebben. Tja, niet iedere gebruiker is zo netjes en clever om de SSH sleutels van een password te voorzien. Server side kun je dat ook niet afdwingen.!
Nog funnier dan; als je een password op de SSH key zet, dan is al het gemak weer van die password-less SSH login foetsie en dan gaan heel wat ansible mensen hard aan de piepel :).!
Getuigt van weinig kennis. Meeste (menselijke) gebruikers van SSH werken vanuit een omgeving waarin een ssh-agent zorgt voor de authenticatie waardoor de gebruiker niets steeds een wachtzin hoeft in te geven opdat de sleutel gebruikt kan worden. (zit je onder MS Windows ?)Het komt er dus op neer dat je server side of met een 2FA aan de slag moet waarbij er het liefst geen shared secret voorheen heeft moetne uitgewisseld zijn tussen de betreffende client en server (dus dingen zoals google-authenticator en TOTPs alleen via een yubikey oid), danwel je hebt [daarbij] een fatsoenlijk password quality beleid dat rekening houdt met menselijk gedrag (accepteer lange passwords die niet veel te complex zijn voor mensen met allerlij rare tekentjes: i.e. de wel bekende "correct horse battery staple" : https://xkcd.com/936/ ).
Secrutiy betreft mensen, je moet gedrag van mensen in je beschouwingen mee nemen!
Ik kan je in dit verband niet goed volgen over shared secrets, maar over 2FA: In praktische implementaties dan veelal met als resultaat dat bij volgende authenticaties vanuit zelfde context (toepassing vanaf zelfde host) de tweede factor niet meer hoeft te worden gepresenteerd. De autorisatie wordt dan vaak belichaamd door een uniek token. Het proces is dan eerder te typeren als een verzwaarde authenticatie ter autorisatie van een bepaald account voor een bepaald gebruik. In het geval van SSH zou de 2FA dan kunnen dienen om de registratie van de SSH public key als toegangsmiddel te autoriseren.Secrutiy betreft mensen, je moet gedrag van mensen in je beschouwingen mee nemen!
Door Anoniem: Geen idee bij welke bank en in welk land deze vermeende kwetsbaarheid speelde. Voor onderstaande off-topic discussie waarschijnlijk ook volstrekt irrelevant. Maar goed.
Door Anoniem:
ha ha ha funny hoor... als admin van een machine met veel gebruikers heb ik zo toegang tot al die SSH sleutels van die gebruikers en dus ook meteen toegang tot al die machines waar ze password-less SSH opgezet hebben. Tja, niet iedere gebruiker is zo netjes en clever om de SSH sleutels van een password te voorzien. Server side kun je dat ook niet afdwingen.!
Wel kan men de autorisatie van de SSH public key intrekken als zou blijken dat een gebruiker zich niet aan de beveiligingsvoorschriften houdt. Technisch afdwingen, niet persé, met procedureel afdekken kom je ook een eind. Premisse is dat de "gebruikers" binnen dezelfde organisatie vallen, althans aan dezelfde voorschriften kunnen worden opgelegd.Door Anoniem: "make extensive use of the Pluggable Authentication Module (PAM) based backdoor we track as SLAPSTICK to aid with credential harvesting, and to provide backdoor access to compromised machines in victim networks."
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
Kan wel speculeren maar schiet niet op. Lijkt er op dat ze oa. een authenticatie probleempje hebben. Als je geen password logins met SSH toestaat dan lijkt me credential harvesting ook niet effectief.
Red teams wins. Blue team loses.
NEXT
ha ha ha funny hoor... als admin van een machine met veel gebruikers heb ik zo toegang tot al die SSH sleutels van die gebruikers en dus ook meteen toegang tot al die machines waar ze password-less SSH opgezet hebben. Tja, niet iedere gebruiker is zo netjes en clever om de SSH sleutels van een password te voorzien. Server side kun je dat ook niet afdwingen.!
Nog funnier dan; als je een password op de SSH key zet, dan is al het gemak weer van die password-less SSH login foetsie en dan gaan heel wat ansible mensen hard aan de piepel :).!
Getuigt van weinig kennis. Meeste (menselijke) gebruikers van SSH werken vanuit een omgeving waarin een ssh-agent zorgt voor de authenticatie waardoor de gebruiker niets steeds een wachtzin hoeft in te geven opdat de sleutel gebruikt kan worden. (zit je onder MS Windows ?)Het komt er dus op neer dat je server side of met een 2FA aan de slag moet waarbij er het liefst geen shared secret voorheen heeft moetne uitgewisseld zijn tussen de betreffende client en server (dus dingen zoals google-authenticator en TOTPs alleen via een yubikey oid), danwel je hebt [daarbij] een fatsoenlijk password quality beleid dat rekening houdt met menselijk gedrag (accepteer lange passwords die niet veel te complex zijn voor mensen met allerlij rare tekentjes: i.e. de wel bekende "correct horse battery staple" : https://xkcd.com/936/ ).
Secrutiy betreft mensen, je moet gedrag van mensen in je beschouwingen mee nemen!
Ik kan je in dit verband niet goed volgen over shared secrets, maar over 2FA: In praktische implementaties dan veelal met als resultaat dat bij volgende authenticaties vanuit zelfde context (toepassing vanaf zelfde host) de tweede factor niet meer hoeft te worden gepresenteerd. De autorisatie wordt dan vaak belichaamd door een uniek token. Het proces is dan eerder te typeren als een verzwaarde authenticatie ter autorisatie van een bepaald account voor een bepaald gebruik. In het geval van SSH zou de 2FA dan kunnen dienen om de registratie van de SSH public key als toegangsmiddel te autoriseren.Secrutiy betreft mensen, je moet gedrag van mensen in je beschouwingen mee nemen!
Ik kan me er wel iets bij voorstellen maar als admin zou ik er (ook) geen genoegen mee nemen (het Ansible verhaal). Besides Ansible impllceert "admin" (naar mijn mening tenminste) dus dat is dan inderdaad of incompetentie of nalatigheid. Ik zelf gebruik (en adviseer) GPG (usb) smartcard (en dus gpg/ssh-agent, Is ook een vorm van 2fa).
Ik begrijp de redenatie dus wel in grote lijnen maar ik zou het zelf zo niet aanpakken.
Wel kan men de autorisatie van de SSH public key intrekken als zou blijken dat een gebruiker zich niet aan de beveiligingsvoorschriften houdt. Technisch afdwingen, niet persé, met procedureel afdekken kom je ook een eind. Premisse is dat de "gebruikers" binnen dezelfde organisatie vallen, althans aan dezelfde voorschriften kunnen worden opgelegd.
Ik zou periodiek key's controlleren op zwaktes en dan of die personen informeren/helpen het probleem op te lossen of desnoods de key's verwijderen (en dus het account blokkeren). Ik ben tenslotte de admin en daarmee de baas/verantwoordelijk. Maar ja ik weet niet hoe dat in andere organisaties werkt.
Door Anoniem:
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Server side kun je dat ook niet afdwingen
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Nope. SSH key staat client side, server side kun je niets afdwingen dat die client key enrypted moet zijn protected met een password.
"Getuigt van weinig kennis. Meeste (menselijke) gebruikers van SSH werken vanuit een omgeving waarin een ssh-agent zorgt voor de authenticatie waardoor de gebruiker niets steeds een wachtzin hoeft in te geven opdat de sleutel gebruikt kan worden. (zit je onder MS Windows ?)"
denk hier nog eens een keertje goed over na... er is niets dat server side afdwingt dat ssh toegang alleen via agent forward mag en dat ssh key client side encrypted / password protected had moeten zijn... je hebt ook geen 100% controle over alle clients (denk zelf maar na waarom niet)...
denk hier nog eens een keertje goed over na... er is niets dat server side afdwingt dat ssh toegang alleen via agent forward mag en dat ssh key client side encrypted / password protected had moeten zijn... je hebt ook geen 100% controle over alle clients (denk zelf maar na waarom niet)...
"Ik kan je in dit verband niet goed volgen over shared secrets"
de std TOTP / google authenticator dingen werken op basis van een shared secret (de QR code die je scan bijv). Als die code op de client staat waarmee je SSH toegang proberet te krijgen, is er geen spraken meer van 2FA eigenlijk. Een client die compromised is dan, die heeft toegang tot alles met keylogging en de shared secret en de ssh key alles netje convenient op datzelfde plekje als die gebruiker. de shared secret voor TOTPs moet dus niet via QR code op client komen, maar in een hardware congle zoals yubikey bijv. via een ander medium voordat het een echte 2FA is.
Veel beter, maar lastiger, is een TOTP genereren dmv een asymmetrisch diffie-hellman : https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
de DH genereert een unieke sessie sleutel die de shared secret is voor een TOTP voor een bepaalde realtief korte periode. de private DH sleutel moet p een yubi key staan dan en het TOTP gedeelte helpt je en beschermt je tegen acute keylogging en credential replay op een mogelijke compromised client.
weet eigenlijk niet of dit al bestaat, gedaan wordt, of dat ik toch een klein denk foutje begaan ben :)...
de std TOTP / google authenticator dingen werken op basis van een shared secret (de QR code die je scan bijv). Als die code op de client staat waarmee je SSH toegang proberet te krijgen, is er geen spraken meer van 2FA eigenlijk. Een client die compromised is dan, die heeft toegang tot alles met keylogging en de shared secret en de ssh key alles netje convenient op datzelfde plekje als die gebruiker. de shared secret voor TOTPs moet dus niet via QR code op client komen, maar in een hardware congle zoals yubikey bijv. via een ander medium voordat het een echte 2FA is.
Veel beter, maar lastiger, is een TOTP genereren dmv een asymmetrisch diffie-hellman : https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
de DH genereert een unieke sessie sleutel die de shared secret is voor een TOTP voor een bepaalde realtief korte periode. de private DH sleutel moet p een yubi key staan dan en het TOTP gedeelte helpt je en beschermt je tegen acute keylogging en credential replay op een mogelijke compromised client.
weet eigenlijk niet of dit al bestaat, gedaan wordt, of dat ik toch een klein denk foutje begaan ben :)...
Door Anoniem:
Nope. SSH key staat client side, server side kun je niets afdwingen dat die client key enrypted moet zijn protected met een password.
Door Anoniem:
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Server side kun je dat ook niet afdwingen
In principe kan je dat trouwens wel. Doet uiteindelijk niet af aan "Secrutiy betreft mensen,"
Admins zijn ook mensen
Nope. SSH key staat client side, server side kun je niets afdwingen dat die client key enrypted moet zijn protected met een password.
Ok ik begrijp je. Is denk ik alleen niet relevant voor dit topic (kan het mis hebben). Ik vermoed dat het hier gaat om een soort van "jump server" (kan het mis hebben)
Door Anoniem: "Ik kan je in dit verband niet goed volgen over shared secrets"
de std TOTP / google authenticator dingen werken op basis van een shared secret (de QR code die je scan bijv). Als die code op de client staat waarmee je SSH toegang proberet te krijgen, is er geen spraken meer van 2FA eigenlijk. Een client die compromised is dan, die heeft toegang tot alles met keylogging en de shared secret en de ssh key alles netje convenient op datzelfde plekje als die gebruiker. de shared secret voor TOTPs moet dus niet via QR code op client komen, maar in een hardware congle zoals yubikey bijv. via een ander medium voordat het een echte 2FA is.
de std TOTP / google authenticator dingen werken op basis van een shared secret (de QR code die je scan bijv). Als die code op de client staat waarmee je SSH toegang proberet te krijgen, is er geen spraken meer van 2FA eigenlijk. Een client die compromised is dan, die heeft toegang tot alles met keylogging en de shared secret en de ssh key alles netje convenient op datzelfde plekje als die gebruiker. de shared secret voor TOTPs moet dus niet via QR code op client komen, maar in een hardware congle zoals yubikey bijv. via een ander medium voordat het een echte 2FA is.
Je moet bedenken dat een volledig compromised client gewoon ongeschikt is als client.
Ook als het tweede-factor credential niet rechtstreeks lekt - de controlerende partij van de client kan gewoon meeliften in/met de SSH sessie (of de TLS sessie, of de VPN sessie) .
De werkelijke gebruiker authenticeert, en de malicious actor profiteert .
Alle crypto-garanties zijn alleen maar geldig zolang de endpoints trusted zijn.
Het is precies wat banking malware doet bij Man In The Browser aanvallen - alle TLS/SSL wordt netjes afgehandeld, de eindgebruiker authenticeert met z'n tweede factor, en de malware doet een andere transactie .
Het is een klein beetje pech voor de aanvaller dat in z'n situatie niet voldoende credentials gestolen kunnen worden om de toegang van de valide gebruiker volledig (op andere tijd en plaats) over te nemen, maar voor ongeveer alle gevallen is meeliften met een valide gebruiker meer dan genoeg voor het doel van een aanvaller.
Door Anoniem: "Getuigt van weinig kennis. Meeste (menselijke) gebruikers van SSH werken vanuit een omgeving waarin een ssh-agent zorgt voor de authenticatie waardoor de gebruiker niets steeds een wachtzin hoeft in te geven opdat de sleutel gebruikt kan worden. (zit je onder MS Windows ?)"
denk hier nog eens een keertje goed over na... er is niets dat server side afdwingt dat ssh toegang alleen via agent forward mag en dat ssh key client side encrypted / password protected had moeten zijn... je hebt ook geen 100% controle over alle clients (denk zelf maar na waarom niet)...
denk hier nog eens een keertje goed over na... er is niets dat server side afdwingt dat ssh toegang alleen via agent forward mag en dat ssh key client side encrypted / password protected had moeten zijn... je hebt ook geen 100% controle over alle clients (denk zelf maar na waarom niet)...
De SSH server kan inderdaad niets afdwingen anders dan de authenticatie methodes die het (niet) ondersteunt en het kan zekere eisen stellen aan de gebruikte keys (cijfer, lengte). Maar goed, de opmerking over gebruik van een ssh-agent sloeg niet daarop: het was een reactie op (het overigens denigrerende):
"Nog funnier dan; als je een password op de SSH key zet, dan is al het gemak weer van die password-less SSH login foetsie en dan gaan heel wat ansible mensen hard aan de piepel :).!"
De notie ".. geen 100% controle ..." laat weinig ruimte voor nuances; het diskwalificeert bij voorbaat veel dat wel helpt.Het is een klein beetje pech voor de aanvaller dat in z'n situatie niet voldoende credentials gestolen kunnen worden om de toegang van de valide gebruiker volledig (op andere tijd en plaats) over te nemen, maar voor ongeveer alle gevallen is meeliften met een valide gebruiker meer dan genoeg voor het doel van een aanvaller.
Goed punt. De integriteit van het systeem is compleet gecompromitteerd.
"Je moet bedenken dat een volledig compromised client gewoon ongeschikt is als client."
en was er maar een manier om dat server side te zien of een client compromised is... oh wacht...
en was er maar een manier om dat server side te zien of een client compromised is... oh wacht...
'De notie ".. geen 100% controle ..." laat weinig ruimte voor nuances; het diskwalificeert bij voorbaat veel dat wel helpt.'
de betwisting is 'wel helpt'.
er staat een helehoop gebruikersongemak tegenover en het is niet zo ondenkbaar dat een windows PC (de client) met een of andere malware infected is waarbij er een keylogger is en waarbij de SSH key files ook powned zijn.
de betwisting is 'wel helpt'.
er staat een helehoop gebruikersongemak tegenover en het is niet zo ondenkbaar dat een windows PC (de client) met een of andere malware infected is waarbij er een keylogger is en waarbij de SSH key files ook powned zijn.
Door Anoniem: Slowaris? Ben ik al 20 jaar niet meer tegengekomen..
Overdrijven is ook een vak - in 2001 was Solaris echt nog groot in heel veel Unix gebaseerde omgevingem.
En nog steeds - blijkbaar - in gebruik bij sommige financials - geen verrrassing gezien de reputatie dat ze daar heel conservatief zijn in platform wijzigingen.
Of bedoel je alleen dat je in 2001 van school gekomen bent en sindsdien Windows beheer gedaan hebt ?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.