Hoeveel social engineering skills heb je nodig... In het verleden heb ik eens een domeinhoster van een klant gebeld met het verzoek om MX records aan te passen van het domein van de klant. Zonder vragen te stellen werd dit gedaan. Het was legitiem, maar achteraf besefte ik dat dit veel te gemakkelijk was gegaan. Dit speelde zich af ergens begin jaren 2000. Security was nog niet zo'n ding.

Tja, op deze manier kan je net zo goed helemaal geen beveiliging implementeren, net zo handig voor je gebruikers...

Toch maar met een Yubikey of iets dergelijks werken de volgende keer...

buy cheap, buy twice.

"gewoon netjes vragen?"

Ik krijg hier een Kevin Mitnick vibe bij :)

Je hebt moeite met lezen en denkt dat technische speeltjes alles oplossen ?

Helpdesk bellen dat je yubikey kwijt is en dat je even een password nodig hebt . DAT was het probleem, dat dat genoeg was.

Oh gebeurt nog steeds.

Ben zelf eind verantwoordelijke voor een hosting provider en zien zo vaak dat als we namens een klant een DNS aanvraag doen naar andere providers dat ze dit zonder comentaar uitvoeren. Vaak is een cc van een klant niet eens nodig als we al eerder contact hebben gehad als afdeling. We zijn al jaren gestopt met ze erop attenderen kost te veel tijd en ook niet ons probleem, nog bedrijf.

Bij onszelf moet de aanvraag vanaf een toegestane contactpersoon en bedrijfs domein komen welke opgenomen staan in het CRM als geautoriseerd en waar we mailheaders ook eerst controleren. Of telefonisch via al bekend nummer in CRM waar wij hun dan op terugbellen voor verificatie dat de aanvraag legitiem is.

En je raadt het al geen enkele zakelijke klant vindt dat een probleem dat we even erachter aan bellen. Dus ik snap werkelijk niet waarom het gewoon geen standaard procedure is bij alle providers. Je kan gewoon al meer dan een decenia niet erop vertrouwen dat een aanvraag legitiem is zonder controle zeker nu met opmars van deepfake en voice cloning wat echt kind eenvoudig is geworden. De enige verdediging tegen social engineering is standaard alles wantrouwen helaas. Maar het werkt wel.

Dus… even samenvatten: een ransomwaregroep met de naam Scattered Spider belt gewoon de helpdesk op, doet een “ik-ben-mijn-wachtwoord-vergeten”-actje, en krijgt netjes de sleutels tot het netwerk. 380 miljoen schade. Geen zero-day, geen quantum-hacking, gewoon een ouderwets belletje. Als dit een Netflix-serie was, zou ik zeggen: “Beetje ongeloofwaardig, hoor.”

En dan Cognizant: “Wij waren niet verantwoordelijk voor cybersecurity.” Oké, maar als je helpdesk vrolijk wachtwoorden rondstrooit alsof het kortingsbonnen voor bleekmiddel zijn, dan heb je misschien iets meer verantwoordelijkheid dan “alleen maar de telefoon opnemen”. MFA-probleem? Reset maar even. Wachtwoord kwijt? Geen probleem, hier is je digitale goudstaaf.

Het mooiste: er liggen waarschuwingen van FBI, Microsoft en Mandiant dat deze truc al jaren populair is. Dus wie heeft er serieus gedacht: “Ach, social engineering, dat zal ons niet overkomen”? Newsflash: dit is niet eens social engineering 2.0, dit is social engineering uit het plakboek van 1998.

Conclusie: ransomware is eng, maar menselijke goedgelovigheid is nog steeds het beste exploit-framework. Misschien dat Clorox voortaan niet alleen schoonmaakt, maar ook hun processen desinfecteert.

Misschien hebben ze daar ook security experts die Post Quantum Crypto hoge prioriteit geven (want dat is zo gaaf of eng of hot in de business).

Als je alleen beperkte helpdeskdiensten levert en geen cybersecurity dan hoor je in mijn ogen helemaal geen wachtwoorden te kunnen afgeven. Ik neem trouwens aan dat ze dan eerst een wachtwoord gereset hebben en dat daartoe dan ook bevoegd zijn bij die helpdesk, anders zou het hier om ongehashte wachtwoorden gaan die de helpdesk kan lezen. Zo idioot zal het niet in elkaar zitten, neem ik aan.

Ze doen dus kennelijk een taak die ik wel degelijk tot cybersecurity zou rekenen. Clorox heeft die aan ze uitbesteed, ze bevoegdheden gegeven om het te kunnen doen, en is kennelijk niet op het lumineuze idee gekomen dat je je daarbij kan afvragen wat daar fout mee zou kunnen gaan, daar goede afspraken over te maken en af en toe met een telefoontje te testen of die goed worden uitgevoerd. Als men daarbij dan toch was gaan nadenken had men zich ook kunnen afvragen of bijvoorbeeld 2FA wat zou toevoegen.

Bij management hoort behalve rekening houden met wat iets aan fijne dingen oplevert ook dat je rekening houdt met wat er mis mee kan gaan en daar voorzieningen voor treffen. Ik heb ooit als IT'er trainingen gehad daarin, die eigenlijk op management gericht waren, bij een werkgever die vond dat behalve managers ook de bouwers en beheerders van de IT-systemen die vaardigheden moesten hebben. Het was een verzameling methodes die eigenlijk neerkwamen op heel gestructureerd en logisch nadenken, die al al in de jaren 1960 waren ontwikkeld. Voor managers dus. Maar ik krijg regelmatig de indruk dat management tegenwoordig vooral gaat over juridisch indekken dat je naar een ander kan wijzen voor de aansprakelijkheid als er iets fout gaat, en nauwelijks nog over nadenken over hoe je voorkomt dat het fout gaat.

Wordt management tegenwoordig teveel vanuit een juridisch perspectief gedaan waarin aansprakelijkheid de hoofdrol speelt? Als dat zo is: geen wonder dat het op zoveel plaatsen zo'n puinhoop is. Je doel moet zijn dat het om te beginnen niet misgaat zodat je in de praktijk niet eens aan gedoe rond die aansprakelijkheid toekomt. Als je moet gaan knokken over wie nou precies de schuld krijgt ben je al te laat. Je moet die juridische kant zeker niet overslaan, die is belangrijk als het toch misgaat, maar dat is een vangnet waarvan je wilt voorkomen dat je het nodig hebt.

In het eerdere bericht (eerste link in het artikel) wordt een jaaromzet van 7,1 miljard dollar gemeld van Clorox. Met zo'n omzet zou men zich toch enige professionaliteit moeten kunnen permitteren...