Vechten tegen de bierkaai

 

Afbeelding via Pixabay

Mijn zoekopdracht leverde 359 documenten op. Toegegeven, een paar daarvan gingen over onderzoeken naar en klaagzangen over het gezochte fenomeen. Maar dan blijven er toch nog zo’n 350 documenten over waarin collega’s het zonder blikken of blozen hadden opgeschreven: Welkom01.

Als je vroeger van vakantie terugkwam en je wachtwoord niet meer wist, dan moest je de helpdesk bellen. Je kreeg dan vaak Welkom01 als nieuw wachtwoord. Ik ben toen eens met ze gaan praten en heb ze uitgelegd dat dat niet zo’n goed idee was. Iederéén kreeg immers datzelfde wachtwoord. Waarschijnlijk was de gedachte: dit is gemakkelijk voor de gebruiker en na de eerste keer inloggen moet hij toch een nieuw wachtwoord instellen. Maar ja, als ik slechte bedoelingen heb en op voorhand al weet wat andermans nieuwe wachtwoord zal zijn, dan kan ik daar wel wat mee. De helpdesk kwam tot inzicht en stapte over op gegenereerde – en dus onvoorspelbare – wachtwoorden. Alweer jaren geleden is deze dienstverlening weggeautomatiseerd en zo kwam er een eind aan Welkom01.

Maar niet heus, getuige de resultaten van mijn zoekopdracht. Overigens wist ik al vooraf wat ik zou aantreffen, want het blijft een gevecht tegen de bierkaai. Wij zijn een organisatie waar applicaties en infrastructuur worden gebouwd. Natuurlijk moeten die spullen getest worden. Dat gebeurt vaak geautomatiseerd of op z’n minst in teamverband. Voor zo’n test heb je geldige user-id’s nodig, met bijbehorende wachtwoorden. En juist omdat het testen geen solitaire bezigheid is, moeten alle teamleden, die erbij betrokken zijn, de wachtwoorden van de testaccounts hebben. Dat snap ik. Twee andere dingen snap ik niet: het wachtwoord dat men kiest, en dat ik daar achter kan komen.

Om maar met het dat eerste te beginnen: kom op mensen, Welkom01! Kun je nou echt niks beters bedenken? Ja oké, er zitten een hoofdletter en maar liefst twee cijfers in. Poeh poeh. De grote zwakte zit ‘m natuurlijk in de voorspelbaarheid van het wachtwoord. Er wordt besmuikt gegniffeld als dit wachtwoord wordt genoemd, omdat we met z’n allen weten dat het op zoveel plekken wordt gebruikt. Effectief betekent het dat ik je wachtwoord weet. En velen met mij. Je weet dat dit niet de bedoeling is.

Mijn tweede sneer is voor het feit dat ik honderden hits op mijn zoekopdracht kreeg. Ik heb geen speciale toverkracht die mij toegang tot alle informatie geeft. Dat betekent dat al die interne pagina’s, waarop wordt uitgelegd hoe en waarmee je van alles en nog wat kunt testen, niet zijn afgeschermd. En dat dus iedereen erbij kan. Je legt daarmee je huissleutel onder de bloempot, beste collega.

Ach, het zijn toch maar testaccounts, hoor ik je zuchten. In productie zouden we dat nooit doen! Waarom dan wel in test? Het is een kleine moeite om (a) een fatsoenlijk wachtwoord te laten genereren en (b) dat wachtwoord vervolgens fatsoenlijk te beschermen. Het heeft allemaal te maken met houding en gedrag. Zoals ik ervan overtuigd ben dat veilig gedrag in je privé-omgeving uitstraalt naar het werk, zo ben ik er ook van overtuigd dat je gedrag in de ene omgeving je gedrag in de andere beïnvloedt; laksheid links leidt gemakkelijk tot een “ik doe het rechts ook maar even zo”-houding als er snel iets moet worden gefixt. En als het probleem is opgelost, vergeet iedereen dat er nog iets moest worden rechtgezet.

Vroeger viel het misschien nog wel mee. Toen had je een strikte scheiding tussen ontwikkel- en beheerwerkzaamheden. Met de komst van devops is die grens vervaagd: in veel teams voeren alle medewerkers alle werkzaamheden uit – dus zowel development als operations, ofwel: ze ontwikkelen én beheren. En moeten dus overal bij kunnen. Dwars door alle OTAP-straten heen. Dat zijn gescheiden omgevingen voor ontwikkeling, test, acceptatie en productie. Maar als je overal bij kunt, dan kun je gedrag uit de ‘minder spannende’ omgevingen kopiëren naar de omgeving waar het er sowieso wél toe doet. Dat maakt ons kwetsbaar.

De mythe wil dat productiegegevens uitsluitend in de productieomgeving staan. Ja, vroeger gebruikten we testbestanden die uit zuiver fictieve data bestonden. Na een functionele aanpassing werden ook de testdata aangepast of uitgebreid. Dat vindt men tegenwoordig te bewerkelijk. En dus worden (geanonimiseerde) productiedata gebruikt. Maar het blijven productiedata. Combineer dat met die andere mythe dat álle medewerkers superbetrouwbaar zijn, en je hebt een recept voor ongelukken. We kijken graag weg als het om insider threat (dreiging vanuit de eigen organisatie) gaat, maar iedere organisatie heeft statistisch gezien recht op een bepaald percentage zwarte schapen. Maak het hen niet te gemakkelijk. Laten we afspreken dat al die simpele wachtwoorden door iets fatsoenlijks worden vervangen en dat ik al die pagina’s met wachtwoorden, die ik nu open heb staan, volgende week niet meer kan benaderen.

 

En in de grote boze buitenwereld …

• kan dit nieuwe ENISA-dreigingenrapport niets over insider threat melden omdat te weinig meldingen in de openbaarheid komen.
• houdt insider threat niet op als iemand de organisatie verlaat.
• maakt de nieuwe versie van macOS diverse securitytools stuk.
• mengt Russische AI zich in de Amerikaanse verkiezingsstrijd. (Het artikel is een cadeautje van de krant, vandaar de lange link.)
• is een hackwedstrijd niet bedoeld voor echte aanvallen.
• heeft de FBI een Chinees IoT-botnet uit de lucht gehaald.
• maakt jouw apparatuur misschien ook deel uit van dat botnet.
• krijgt de Autoriteit Persoonsgegevens te weinig geld, vindt de AP.
• denken sommige mensen dat AI-camera’s een zegen voor de mensheid zullen zijn.