Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Analyse Equifax hack
Naar aanleiding van diverse artikelen over de datalekken bij Equifax, hebben studenten aan de Fontys Hogeschool ICT CyberSecurity een onderzoek gestart naar deze datalekken. Met onderstaande resultaten als gevolg.
Equifax
Equifax - Van 13 mei tot 30 juli 2017 zijn er meerdere datalekken bij Equifax geweest. Meer dan 143 miljoen persoonsgegevens van individuen in Amerika zijn verkregen door hackers.
Op 2 augustus 2017 heeft Equifax contact opgenomen met het bedrijf Mandiant, een cybersecurity bedrijf dat moet helpen met het achterhalen wat er gestolen is bij het bedrijf Equifax. Hoe heeft dit kunnen gebeuren? Equifax had al vóór 13 mei een rapport liggen waaruit bleek dat hun web applicatie een paar enkele security risico’s had die makkelijk te verhelpen waren. Echter is er al die tijd niks tegen gedaan en heeft het bedrijf te maken gehad met de data hack zoals genoemd is.
Equifax maakte gebruik van een softwarepakket genaamd ‘Apache Struts’. Apache Struts is een Model/View/Controller (MVC) ontwikkelframework voor Java en zorgt voor een simpele manier waarop data verkregen kan worden door web requests. In deze web requests kon een linux commando meegegeven worden die uitgevoerd werden op het systeem. Door simpele een reeks van simpele commando’s kregen de hackers toegang tot het systeem, dit systeem was ook nog niet geüpdatet en had ook enkele flaws hierdoor kon de hacker toegang tot het systeem verkrijgen.
De data lekken van Equifax heeft meerdere gegevens van personen gelekt waar de individuele hun leven lang last van zullen gaan hebben, waaronder:
- Volledige namen
- Burgerservicenummer
- Geboorte datums
- Gegevens over waar ze wonen
- Rijbewijzen
- Credit card gegevens
Deze gegevens kunnen gebruikt worden om identiteitsfraude te verrichten en dit kan erg schadelijk zijn voor de personen, hierdoor kan er veel geld worden afgetroggeld bij de individuen.
Dit lek heeft de CVE-code CVE-2017-5638 gekregen. Op basis van deze CVE kan er geconcludeerd worden dat Apache Struts 2.3.x voor 2.3.32 en 2.5.x voor 2.5.10.1 incorrecte exception-handling en error-message-generation hebben tijdens bestands-uploads. Wat aanvallers op afstand in staat stelt om een Remote Code Execution uit te voeren. Dit is mogelijk door een speciale Content-Type HTTP header in een HEAD request te sturen. De error kan ook getriggerd worden door een speciale Content-Disposition, of een Content-Length HTTP header te sturen. De Content-Type moet een “#cmd=” gedeelte bevatten met daarna het uit te voeren commando.
Om het zelf te testen is het mogelijk om zelf een omgeving op te zetten met een kwetsbare versie van Struts. Er zijn docker-images beschikbaar die een kant-en-klare omgeving bieden om deze kwetsbaarheid te testen.
Een voorbeeld van een docker container is: https://hub.docker.com/r/piesecurity/apache-struts2-cve-2017-5638/, maar er zijn er meer te vinden op https://hub.docker.com/ met de zoekterm CVE-2017-5638.
Nadat er een testomgeving is, kan er ook aan de slag gegaan worden met Proof of Concept. PoC code kan worden gevonden, geschreven in Python, op de volgende link: https://github.com/mazen160/struts-pwn. Ook hier geldt dat er meer PoC code te vinden is op sites zoals GitHub (https://github.com) met als zoekterm het CVE-nummer.
De datalekken komen voort uit ‘te laat’ gepatchte systemen en of applicaties, zoals genoemd was er al eerder een rapport waarin stond dat er risico’s waren met de website. Echter heeft niemand dit aangepast zodat deze risico’s verholpen zijn, zowel de developer’s van dit product als de beheerders van het netwerk hadden toegang tot dit rapport. De developer’s hadden hun/haar code moeten doorkijken naar aanleiding van dit rapport en een update request van deze module (apache struts) kunnen meegeven aan de beheerders. Echter wisten de beheerders van deze security flaws en hadden met een update request kunnen komen naar de beheerders om hun/haar code door te kijken of deze nog zou werken met een geupdate versie van apache struts. Daarbij willen wij vragen aan u: “welke partij had hier beter op moeten letten, en waar ligt de fout?”.
Equifax
Equifax - Van 13 mei tot 30 juli 2017 zijn er meerdere datalekken bij Equifax geweest. Meer dan 143 miljoen persoonsgegevens van individuen in Amerika zijn verkregen door hackers.
Op 2 augustus 2017 heeft Equifax contact opgenomen met het bedrijf Mandiant, een cybersecurity bedrijf dat moet helpen met het achterhalen wat er gestolen is bij het bedrijf Equifax. Hoe heeft dit kunnen gebeuren? Equifax had al vóór 13 mei een rapport liggen waaruit bleek dat hun web applicatie een paar enkele security risico’s had die makkelijk te verhelpen waren. Echter is er al die tijd niks tegen gedaan en heeft het bedrijf te maken gehad met de data hack zoals genoemd is.
Equifax maakte gebruik van een softwarepakket genaamd ‘Apache Struts’. Apache Struts is een Model/View/Controller (MVC) ontwikkelframework voor Java en zorgt voor een simpele manier waarop data verkregen kan worden door web requests. In deze web requests kon een linux commando meegegeven worden die uitgevoerd werden op het systeem. Door simpele een reeks van simpele commando’s kregen de hackers toegang tot het systeem, dit systeem was ook nog niet geüpdatet en had ook enkele flaws hierdoor kon de hacker toegang tot het systeem verkrijgen.
De data lekken van Equifax heeft meerdere gegevens van personen gelekt waar de individuele hun leven lang last van zullen gaan hebben, waaronder:
- Volledige namen
- Burgerservicenummer
- Geboorte datums
- Gegevens over waar ze wonen
- Rijbewijzen
- Credit card gegevens
Deze gegevens kunnen gebruikt worden om identiteitsfraude te verrichten en dit kan erg schadelijk zijn voor de personen, hierdoor kan er veel geld worden afgetroggeld bij de individuen.
Dit lek heeft de CVE-code CVE-2017-5638 gekregen. Op basis van deze CVE kan er geconcludeerd worden dat Apache Struts 2.3.x voor 2.3.32 en 2.5.x voor 2.5.10.1 incorrecte exception-handling en error-message-generation hebben tijdens bestands-uploads. Wat aanvallers op afstand in staat stelt om een Remote Code Execution uit te voeren. Dit is mogelijk door een speciale Content-Type HTTP header in een HEAD request te sturen. De error kan ook getriggerd worden door een speciale Content-Disposition, of een Content-Length HTTP header te sturen. De Content-Type moet een “#cmd=” gedeelte bevatten met daarna het uit te voeren commando.
Om het zelf te testen is het mogelijk om zelf een omgeving op te zetten met een kwetsbare versie van Struts. Er zijn docker-images beschikbaar die een kant-en-klare omgeving bieden om deze kwetsbaarheid te testen.
Een voorbeeld van een docker container is: https://hub.docker.com/r/piesecurity/apache-struts2-cve-2017-5638/, maar er zijn er meer te vinden op https://hub.docker.com/ met de zoekterm CVE-2017-5638.
Nadat er een testomgeving is, kan er ook aan de slag gegaan worden met Proof of Concept. PoC code kan worden gevonden, geschreven in Python, op de volgende link: https://github.com/mazen160/struts-pwn. Ook hier geldt dat er meer PoC code te vinden is op sites zoals GitHub (https://github.com) met als zoekterm het CVE-nummer.
De datalekken komen voort uit ‘te laat’ gepatchte systemen en of applicaties, zoals genoemd was er al eerder een rapport waarin stond dat er risico’s waren met de website. Echter heeft niemand dit aangepast zodat deze risico’s verholpen zijn, zowel de developer’s van dit product als de beheerders van het netwerk hadden toegang tot dit rapport. De developer’s hadden hun/haar code moeten doorkijken naar aanleiding van dit rapport en een update request van deze module (apache struts) kunnen meegeven aan de beheerders. Echter wisten de beheerders van deze security flaws en hadden met een update request kunnen komen naar de beheerders om hun/haar code door te kijken of deze nog zou werken met een geupdate versie van apache struts. Daarbij willen wij vragen aan u: “welke partij had hier beter op moeten letten, en waar ligt de fout?”.
Reacties (13)
Echter heeft niemand dit aangepast zodat deze risico’s verholpen zijn,
Tuurlijk. ;)
16-11-2017, 06:36 door
karma4
Je zegt dat de developers er van af wisten de beheerders de boel hadden kunnen nalopen.
Dit zijn de partijen in het 9 vlaks model voor de basale uitvoering de operatie. Zij hebben geen beslissingsbevoegdheid en geen adviserende rol.
Ontbrekende partijen zijn het strategisch en tactisch gebeuren. Daar worden de beslissingen wie wat wanneer genomen.
Dan heb je nog al die adviserende personen verkopers van producten die aan de beslissers hun beelden brengen.
Als het beeld geschetst is dat je er niets aan hoeft te doen dat anderen dat gratis en voor niets voor jou doen dan komt de rekening vanzelf.
Dit zijn de partijen in het 9 vlaks model voor de basale uitvoering de operatie. Zij hebben geen beslissingsbevoegdheid en geen adviserende rol.
Ontbrekende partijen zijn het strategisch en tactisch gebeuren. Daar worden de beslissingen wie wat wanneer genomen.
Dan heb je nog al die adviserende personen verkopers van producten die aan de beslissers hun beelden brengen.
Als het beeld geschetst is dat je er niets aan hoeft te doen dat anderen dat gratis en voor niets voor jou doen dan komt de rekening vanzelf.
Equifax had al vóór 13 mei een rapport liggen waaruit bleek dat hun web applicatie een paar enkele security risico’s had die makkelijk te verhelpen waren. Echter is er al die tijd niks tegen gedaan en heeft het bedrijf te maken gehad met de data hack zoals genoemd is.
Fout ligt bij de gehele Equifax organisatie (en daarbij natuurlijk de directie) voor het niet hebben van bepaald beleid, procedures en protocollen om met dergelijke situaties om te gaan en hoe hierop te reageren. Daarbij denk ik dat de schuld leggen bij ontwikkelaars niet aan de orde is, tenzij er sprake zou zijn van opzet of bewuste nalatigheid. Developers werken vaak in opdracht van een productmanager of een andere aansturende kracht, en zijn in veel gevallen meer uitvoerend. Indien de bevindingen in het rapport hadden verlangd dat de developers hun code (opnieuw) hadden moeten reviewen of wijzigen, dan had iemand hen hiertoe opdracht moeten geven. Of dit dan taak is van beheerders kan op een zelde manier worden beantwoord: dit ligt aan de hierarchie en de verdeling van bevoegdheden en verantwoordelijkheden binnen de organisatie. Maar ook hier: dit had helder gecommuniceerd moeten zijn d.m.v. bijvoorbeeld procedures, protocollen, beleidsstukken of zelfs functieprofielen.
Overigens weet ik niet wie dit 'artikel' geschreven heeft, maar het is in ieder geval op een wijze geformuleerd waarbij het aan stemmingsmakerij niet tekort komt. Onder meer de onderstaande quote, en de twee "Echter"-zinnen in de laatste alinea zorgen voor wat sturing m.b.t. de conclusie die uit een dergelijk geschreven stuk gehaald kan worden.
De data lekken van Equifax heeft meerdere gegevens van personen gelekt waar de individuele hun leven lang last van zullen gaan hebben
Waar mensen hun leven lang last van KUNNEN hebben.
De studenten komen met grappige bevindingen, echter kun je zien dat het studenten zijn, want het zit ook vol met aannames.
De centralisatie van belangrijke identificerende gegevens van zoveel ontiegelijk veel mensen trekt constant hackers aan.
Je kan je dan niet permitteren om ook maar enkele minuten kwetsbaar te zijn. Maar het beheren van systemen is mensenwerk, en mensen maken fouten. Dat geldt ook voor systeembeheerders en arrogantie doet daar niets van af.
Fouten maken is mens eigen.;Mensen worden na verloop van tijd ook slordig als iets heel lang is goed gegaan.
Dus als je je dan niet kunt permitteren om fouten te maken, kun je je zo'n enorme gecentraliseerde database van identificerende gegevens ook beter uit je hoofd zetten, want vroeg of laat wordt zo'n systeem gehackt.
Daar kan je donder op zeggen.
Het gaat hier dan ook niet zozeer om de schuldvraag van wie er deze keer gefaald heeft met deze grote gevolgen.
Het gaat eigenlijk veel meer over "we hebben dit systeem niet "foolproof" ontworpen, en hoe kunnen we dat beter doen,
en als je dan toch nog wordt gehackt, hoe kunnen we dan de gevolgen ervan redelijk binnen de perken houden."
Je kan je dan niet permitteren om ook maar enkele minuten kwetsbaar te zijn. Maar het beheren van systemen is mensenwerk, en mensen maken fouten. Dat geldt ook voor systeembeheerders en arrogantie doet daar niets van af.
Fouten maken is mens eigen.;Mensen worden na verloop van tijd ook slordig als iets heel lang is goed gegaan.
Dus als je je dan niet kunt permitteren om fouten te maken, kun je je zo'n enorme gecentraliseerde database van identificerende gegevens ook beter uit je hoofd zetten, want vroeg of laat wordt zo'n systeem gehackt.
Daar kan je donder op zeggen.
Het gaat hier dan ook niet zozeer om de schuldvraag van wie er deze keer gefaald heeft met deze grote gevolgen.
Het gaat eigenlijk veel meer over "we hebben dit systeem niet "foolproof" ontworpen, en hoe kunnen we dat beter doen,
en als je dan toch nog wordt gehackt, hoe kunnen we dan de gevolgen ervan redelijk binnen de perken houden."
16-11-2017, 19:10 door
karma4
Door Anoniem: .....
Het gaat eigenlijk veel meer over "we hebben dit systeem niet "foolproof" ontworpen, en hoe kunnen we dat beter doen,
en als je dan toch nog wordt gehackt, hoe kunnen we dan de gevolgen ervan redelijk binnen de perken houden."
Met fool proof houd je enkel de gestoorden buiten de deur.Het gaat eigenlijk veel meer over "we hebben dit systeem niet "foolproof" ontworpen, en hoe kunnen we dat beter doen,
en als je dan toch nog wordt gehackt, hoe kunnen we dan de gevolgen ervan redelijk binnen de perken houden."
Full proof is echter nooit volledig bereikbaar gewoon omdat perfectie niet bestaat.
Door karma4:
Full proof is echter nooit volledig bereikbaar gewoon omdat perfectie niet bestaat.
Door Anoniem: .....
Het gaat eigenlijk veel meer over "we hebben dit systeem niet "foolproof" ontworpen, en hoe kunnen we dat beter doen,
en als je dan toch nog wordt gehackt, hoe kunnen we dan de gevolgen ervan redelijk binnen de perken houden."
Met fool proof houd je enkel de gestoorden buiten de deur.Het gaat eigenlijk veel meer over "we hebben dit systeem niet "foolproof" ontworpen, en hoe kunnen we dat beter doen,
en als je dan toch nog wordt gehackt, hoe kunnen we dan de gevolgen ervan redelijk binnen de perken houden."
Full proof is echter nooit volledig bereikbaar gewoon omdat perfectie niet bestaat.
Zucht - en zucht . Het zal wel weer eens niet dezelfde zijn...
Mensen fout verbeteren , het is een speciaal soort arrogantie - je eigen aannames nooit controleren.
De uitdrukking is wel degelijk 'foolproof' - oftewel , bestand de grootst mogelijke stommiteiten in bediening/gebruik/interpretatie - "Want welke idioot gaat er nou ook ... doen " - als je apparaat, proces, handleiding ook daar tegen kan is het _fool_proof .
'Full proof' - "volledig bestendig" klinkt misschien logisch maar is gewoon geen bestaande Engelse uitdrukking voor een heel erg robuust ding.
https://en.wiktionary.org/wiki/foolproof
(ook wel - idiotproof, monkeyproof )
https://www.merriam-webster.com/dictionary/foolproof
16-11-2017, 22:12 door
Bitwiper
Door Fontys Cyber security: welke partij had hier beter op moeten letten, en waar ligt de fout?
In grote organisaties kun je als directeur niet alles controleren, maar je bent wel eindverantwoordelijk. Het is dan ook onvermijdelijk en essentieel dat verantwoordelijkheden zorgvuldig worden gedelegeerd.Niet voor niets is in de BIR-TNK (Baseline Informatiebeveiliging Rijksdienst - Technisch Normen Kader), die een uitbreiding vormt op de controls uit ISO 27001/27002, een duidelijke rol weggelegd voor het lijnmanagement. Als directie ben je er zeker verantwoordelijk voor dat alle verantwoordelijkheden goed (zonder gaten en overlaps) zijn afgedekt, en lege plekken (vakantie, ziekte, andere functie) ogenblikkelijk worden opgevuld - maar de praktijk is vaak weerbarstiger.
Los van formele procedures hoor je als directie en management ook je uiterste best te doen om waarschuwingssignalen van ondergeschikten op te pakken. Ik vermoed dat er maar weinig security-incidenten plaatsvinden waar dat soort signalen er vooraf niet waren (denk aan klachten over te grote werkdruk of onvoldoende middelen om je werk goed en secure te kunnen doen).
Mijn persoonlijke ervaring in grotere organisaties is dat, als je misstanden aan direct leidinggevenden meldt, er niets mee gedaan wordt - omdat ze het te druk hebben (d.w.z. de risico's onderschatten en daarom anders prioriteren) en/of oplossingen van hun afdelingsbudget af gaan. Toen ik een keer enkele fikse securityrisico's aan de directie meldde, en die directie opdracht gaf om e.e.a. te onderzoeken, was de leidinggevende vooral boos dat ik "de lijn had gepasseerd". Uiteindelijk veranderde er niets. Organisaties zonder "wij-gevoel" van top tot teen zijn gedoemd om, vroeger of later, flink tegen de lamp te lopen.
Zodra hoge leidinggevenden, zoals naar verluidt in de Equifax zaak, de schuld bij een individuele werknemer leggen die een patch niet zou hebben geïnstalleerd, weet ik al over wat voor een organisatie we het hebben. Daar wil je niet werken - en ook geen zaken (meer) mee doen.
17-11-2017, 06:52 door
karma4
Door Bitwiper: .......
Zodra hoge leidinggevenden, zoals naar verluidt in de Equifax zaak, de schuld bij een individuele werknemer leggen die een patch niet zou hebben geïnstalleerd, weet ik al over wat voor een organisatie we het hebben. Daar wil je niet werken - en ook geen zaken (meer) mee doen.
Bitwiper je bent mij niet. Uitstekend verwoord :<)Zodra hoge leidinggevenden, zoals naar verluidt in de Equifax zaak, de schuld bij een individuele werknemer leggen die een patch niet zou hebben geïnstalleerd, weet ik al over wat voor een organisatie we het hebben. Daar wil je niet werken - en ook geen zaken (meer) mee doen.
De developer’s hadden hun/haar code moeten doorkijken naar aanleiding van dit rapport en een update request van deze module (apache struts) kunnen meegeven aan de beheerders. Echter wisten de beheerders van deze security flaws en hadden met een update request kunnen komen naar de beheerders om hun/haar code door te kijken of deze nog zou werken met een geupdate versie van apache struts. Daarbij willen wij vragen aan u: “welke partij had hier beter op moeten letten, en waar ligt de fout?”.
Bij het management team als eindverantwoordelijke, waar anders ? Immers moeten zij in control zijn m.b.t. dit soort issues, waarbij developers en beheerders enkel verantwoordelijk zijn voor de uitvoering.
Zowel indien uitvoerenden het oplossen zijn 'vergeten', als ook indien zij geen tijd/toestemming kregen om het te verhelpen tgv andere 'meer urgente' werkzaamheden, is het uiteindelijk een issue voor het management team.
Slordig werk....
Erg goede formulering....
Een data lek lekt ? Verder is het ''een data lek heeft'' of ''data lekken hebben''
Is het enige risico van identiteitsfraude het aftroggelen van geld bij ''de individuen'' ? Indien men mijn identiteit steelt, is het risico nou niet direkt dat men bij mij geld gaat aftroggelen. Hebben de studenten echt nagedacht over de mogelijk impact ?
En het management team, dat verantwoordelijk is voor de aansturing ?
De hoofdverantwoordelijken worden door de studenten niet genoemd, enkel uitvoerend personeel. Misschien moeten ze zich nog wat meer verdiepen in de vraag waar de eindverantwoordelijkheid ligt binnen ondernemingen. En ook over het feit dat personeel vaak helemaal niet zelf bepaalt waar de prioriteiten liggen m.b.t. hoe zij hun tijd indelen.
Door simpele een reeks van simpele commando’s
Erg goede formulering....
De data lekken van Equifax heeft meerdere gegevens van personen gelekt
Een data lek lekt ? Verder is het ''een data lek heeft'' of ''data lekken hebben''
Deze gegevens kunnen gebruikt worden om identiteitsfraude te verrichten en dit kan erg schadelijk zijn voor de personen, hierdoor kan er veel geld worden afgetroggeld bij de individuen.
Is het enige risico van identiteitsfraude het aftroggelen van geld bij ''de individuen'' ? Indien men mijn identiteit steelt, is het risico nou niet direkt dat men bij mij geld gaat aftroggelen. Hebben de studenten echt nagedacht over de mogelijk impact ?
Echter heeft niemand dit aangepast zodat deze risico’s verholpen zijn, zowel de developer’s van dit product als de beheerders van het netwerk hadden toegang tot dit rapport
En het management team, dat verantwoordelijk is voor de aansturing ?
Daarbij willen wij vragen aan u: “welke partij had hier beter op moeten letten, en waar ligt de fout?”.
De hoofdverantwoordelijken worden door de studenten niet genoemd, enkel uitvoerend personeel. Misschien moeten ze zich nog wat meer verdiepen in de vraag waar de eindverantwoordelijkheid ligt binnen ondernemingen. En ook over het feit dat personeel vaak helemaal niet zelf bepaalt waar de prioriteiten liggen m.b.t. hoe zij hun tijd indelen.
waar de individuele hun leven lang last van zullen gaan hebben
Individuen of individuele ?
17-11-2017, 18:14 door
Bitwiper
Door Anoniem: Slordig werk....
Denk je serieus dat mensen beter Nederlands gaan schrijven n.a.v. jouw kritiek, of is het jouw bedoeling om mensen die beter zijn (of willen worden) in security van dit forum te verjagen?Door Anoniem: Indien men mijn identiteit steelt, is het risico nou niet direkt dat men bij mij geld gaat aftroggelen.
Vermoedelijk is identiteitsdiefstal via betaalpassen en internetbankieren de meest voorkomende vorm. Equifax is notabene een bedrijf dat daartegen bescherming verkoopt (naar verluidt het eerste jaar gratis en daarna 16 of 17 US$ per maand). Kennelijk maken zeer veel Amerikanen gebruik van deze "dienst". In https://youtu.be/e6fIuRqu6wc kun je zien hoe senator Warren de (sinds kort) ex CEO dhr. Smith laat bevestigen dat ook deze hack Equifax uiteindelijk meer goed doet dan kwaad (elk lek van persoonsgegevens is in hun belang, ondanks eerdere lekken bij Equifax bleef de winst maar stijgen).Door Anoniem: De hoofdverantwoordelijken worden door de studenten niet genoemd, enkel uitvoerend personeel. Misschien moeten ze zich nog wat meer verdiepen in de vraag waar de eindverantwoordelijkheid ligt binnen ondernemingen. En ook over het feit dat personeel vaak helemaal niet zelf bepaalt waar de prioriteiten liggen m.b.t. hoe zij hun tijd indelen.
Een les voor de studenten is wat mij betreft dat ze wat meer achtergronden zouden moeten geven. Ik vermoed (weet dus niet zeker) dat hun vraag voortkomt uit het feit dat de ex CEO dhr. Smith, tijdens zijn verhoor, uiteindelijk 1 medewerker de schuld gaf van het incident (zonder een naam te noemen). Dit gebeurt, naar verluidt onder andere, tijdens het verhoor door senator Franken in https://youtu.be/CQFkY1nuvIo.Dit is m.i. nogal opgeblazen door de sensatiepers (Google: equifax smith testimony), want o.a. in zijn schriftelijke verklaring vooraf geeft dhr. Smith wel degelijk aan eindverantwoordelijk te zijn (http://docs.house.gov/meetings/IF/IF17/20171003/106455/HHRG-115-IF17-Wstate-SmithR-20171003.pdf), terwijl de uitspraak dat het incident kon plaatsvinden doordat 1 medewerker niet had gedaan wat had moeten gebeuren en vervolgens een vulnerability scanner de kwetsbaarheid niet aan het licht bracht, hem tijdens een verhoor op zoek naar de oorzaak zijn ontlokt.
Mijn eerdere conclusie:
Zodra hoge leidinggevenden, zoals naar verluidt in de Equifax zaak, de schuld bij een individuele werknemer leggen die een patch niet zou hebben geïnstalleerd, weet ik al over wat voor een organisatie we het hebben. Daar wil je niet werken - en ook geen zaken (meer) mee doen.
was, na me verder in deze zaak te hebben verdiept, gebaseerd op nepnieuws. Mijn stelling dat je niet bij een organisatie wilt werken waarbij de beveiliging van miljoenen vertrouwelijke persoonsgegevens afhankelijk is van 1 persoon, en dat je met zo'n organisatie ook geen zaken (meer) wilt doen, blijft evenwel overeind. Niet zozeer omdat een hoge leidinggevende 1 medewerker de schuld geeft, maar omdat hij een bedrijf leidde waar het kennelijk goed genoeg gevonden wordt (na eerdere hacks) om een dergelijke verantwoordelijkheid bij 1 persoon te beleggen.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.
