Primary tabs

Zomaar een willekeurige dag. Het systeem waar jij verantwoordelijk voor bent gedraagt zich vreemd; er gebeuren dingen die je niet kan verklaren. Telefoons gaan af, managers worden nerveus, de druk neemt toe. Je moet uitzoeken wat er aan de hand is. Hiervoor moet je toch echt de logfiles induiken die op de server staan. Maar om daar bij te kunnen heb je toegangsrechten nodig. Je wilt natuurlijk ook meteen een oplossing kunnen doorvoeren als je het probleem hebt gevonden. Dus vraag je meteen administrator access aan zodat je configuraties kunt aanpassen. Dit is ontzettend handig en het geeft je meer dan genoeg toegangsrechten om het probleem snel op te lossen en jou tot de held van de dag te maken! Omdat dit zo’n waanzinnig handig account is hou je het actief, zodat je de boel in de gaten kan blijven houden om toekomstige incidenten te voorkomen.

Wederom een willekeurige dag. Jij hebt de opdracht gekregen een nieuw aangekocht softwarepakket te installeren. Hiervoor heb je toegang nodig tot het operating system, dat volgens de eisen geconfigureerd moet worden. Hiervoor vraag je root access; deze worden prompt toegewezen. Omdat het een nieuw pakket is voorzie je dat jij en jouw team waarschijnlijk nog wat meer tijd nodig zullen hebben om het een en ander op de server te finetunen. Daarom deel jij de login gegevens met jouw team. Of beter, je maakt voor iedereen een eigen administrator account aan, zodat jouw teamleden net zoveel macht hebben als jij. Dat scheelt heel veel tijd en stelt jullie in staat om per sprint meer op te leveren.

Machtige accounts

Dit zijn slechts twee voorbeelden van hoe wij neigen om te gaan met high privileged accounts terwijl wij echt het beste voor hebben met het bedrijf. Het zijn hele handige accounts voor het dagelijkse werk; het stelt ons in staat om snel tot de kern van een probleem door te dringen en om snel kleine dingetjes aan te passen in het operating system, de database of andere systeem onderdelen. Accounts die we ook niet zo snel meer opgeven, omdat ze ons niet alleen heel erg machtig doen voelen maar ook daadwerkelijk erg machtig maken!

De keerzijde van het hebben van Superkrachten

Helaas zijn deze accounts ook extreem gevaarlijk. Ze zijn niet alleen heel erg krachtig en in staat om de best beschermde systemen plat te leggen; ze zijn ook het meest gewild bij hackers. Want als zij een dergelijk account in handen hebben, krijgen zij mogelijk ongelimiteerd toegang tot de IT infrastructuur en de data van het bedrijf. En omdat deze accounts hartstikke legitiem zijn kunnen de hackers dit maanden lang doen zonder gedetecteerd te worden! De indringers kunnen zo onopgemerkt de Confidentiality, Integrity en de Availability van de systemen en de data van het bedrijf in gevaar brengen.

Klinkt dit allemaal overdreven en als iets wat alleen in films en Netflix-series plaatsvindt? Veel mensen denken van wel. Wat is het risico, toch? We hebben dit soort accounts gewoon nodig om ons werk goed te doen en natuurlijk zijn wij ONTZETTEND voorzichtig en gaan wij ONTZETTEND verantwoordelijk om met de inloggegevens…

Wat we van Maersk, Uber en anderen kunnen leren

Heel veel mensen bij Maersk dachten dit ook tot een aantal jaar geleden. Helaas voor hen was het onder meer de overvloed aan administrator accounts op hun systemen (en de bijbehorende inloggegevens op de laptops) die de NotPetya ransomware in 2017 in recordtijd hielpen verspreiden door het bedrijf. In slechts 2½ uur lag het bedrijf volledig plat, de kosten van de aanval worden geschat tussen de $250 miljoen en $300 miljoen dollar.

Of dan de beheerders bij Uber? Die dachten in 2016 ook dat ze alles onder controle hadden. Totdat administrator accounts werden gebruikt om de persoonlijke informatie van zo’n 57 miljoen klanten en 600.000 rijbewijzen openbaar te maken. Onder de GDPR-regels van de EU kan dit leiden tot een boete van 4% van hun omzet of $20 miljoen, afhankelijk van welke hoger is… Uiteindelijk bedroeg de schade $148 miljoen. Bij Capital One werd in 2019 een firewall account misbruikt om toegang te krijgen tot de data van zo’n 100 miljoen mensen, de schade wordt door het bedrijf zelf geschat op minimaal $300 miljoen.

Dus administrator en andere accounts met hoge privileges zijn wel degelijk ‘een ding’. Ze moeten echt goed beheerd worden. En elk bedrijf zou de totale controle moeten hebben waar ze zijn, wanneer ze worden gebruikt en wie ze gebruiken.

De krachten leren beheersen

Elke security maatregel is een afweging tussen veiligheid en bruikbaarheid. Zo ook met het gebruik van de ontegenzeggelijk handige administrator accounts. Bij veel bedrijven staat de bruikbaarheid en de mogelijke snelheid van ingrijpen echter vrijwel altijd voorop zonder al teveel rekening te houden met de veiligheid, met alle risico’s van dien.

Hoe kan je dan tot een verandering komen in het gebruik van dergelijke accounts? Om te beginnen zal je als security specialist moeten erkennen dat bruikbaarheid en gebruiksgemak wel degelijk een belangrijke rol speelt. Het inrichten van een hoogstaande omgeving waarin deze accounts technisch goed beveiligd zijn kost tijd en vooral ook geld. Een bedrijf is niet zomaar op dat niveau. Verder is niet elke technische oplossing geschikt voor elke situatie die zich kan voordoen. Het begint daarom met het maken van een groeiplan en afspraken over Governance. Je kan op voorhand een drietal niveaus onderscheiden om toegang te verkrijgen tot de infrastructuur: Ultimate, Advanced en Basic. Deze niveaus variëren van ‘veilig, snel en makkelijk’ toegang tot ‘veilig, langzaam en moeilijk’, zoals ervaren door de persoon die toegang tot de infrastructuur wenst.

Ultimate

De Ultimate manier (veilig, snel en makkelijk) past perfect in de DevOps manier van werken met Infrastructure as Code en CI/CD straten. Alle toegang tot infrastructuur componenten gebeurt enkel via tooling. Mensen krijgen niet langer de beschikking over directe toegang.

De tooling, zoals XLDeploy of Splunk is toegankelijk met de reguliere user IDs en wordt beschikbaar gesteld via Role Based Access. Jouw rol (ontwikkelaar, beheerder, enz.) bepaalt welke functionaliteit jij tot je beschikking krijgt binnen de tooling. Tot welke organisatorische eenheid (team, afdeling, enz.) je behoort bepaalt welke servers je mag benaderen via de tooling. De tooling krijgt de juiste (soms hoge) toegangsrechten tot de infrastructuur zodat je als gebruiker nog steeds dat kan doen wat je moet doen (raadplegen van logfiles, status van de server controleren of code deployment). Wie wat heeft gedaan wordt door de tooling in auditfiles vastgelegd. De inloggegevens van de tooling op de infrastructuur componenten worden veilig opgeborgen in een digitale kluis zoals CyberArk.

Zodra de tooling is ingeregeld en de rollen zijn gedefinieerd, is dit een makkelijke en snelle manier om iedereen de juiste toegang te geven tot de juiste componenten.

Advanced

De Advanced manier komt om de hoek kijken bij omstandigheden die het of onmogelijk of niet praktisch maken om tooling te gebruiken, zodat directe toegang toch nodig is. Dit kan worden opgelost door het beschikbaar stellen van een gedeeld, niet persoonlijk account met hoge toegangsrechten. Dit is een account dat jij en andere mensen kunnen gebruiken als je daar toestemming voor hebt. De inloggegevens liggen opgesloten in een digitale kluis. Het wachtwoord wordt elke keer automatisch gewijzigd nadat het account weer is ‘ingecheckt’. Er mag verder geen enkele twijfel bestaan dat de persoon die het account heeft gebruikt ook dezelfde persoon is die het account heeft uitgecheckt.

Je krijgt toegang tot de kluis met accounts met jouw persoonlijke user ID. Dit kan door middel van een reguliere of een tijdelijk toegekende rol, afhankelijk van hoe kritiek de applicatie is of de situatie die zich dan voordoet. De kluis kan zelfs zo worden ingericht dat een tweede persoon jouw aanvraag goedkeurt of zelfs de kluis voor je opent. Alle acties die vervolgens met dit account worden uitgevoerd worden vastgelegd. Dit maakt dat de Advanced manier veilig is, maar een beetje minder makkelijk door de extra stappen die je moet ondernemen voordat je jouw taken kan uitvoeren.

Basic

Tot slot is er de Basic manier. Deze manier moet ook veilig zijn (anders zou je hem uiteraard nooit aanbieden) maar het moet wel erg moeilijk gemaakt worden om te gebruiken. Deze manier geeft je direct toegang tot infrastructuur componenten met hoge toegangsrechten met een account dat aan jou persoonlijk is toegekend.

Om een dergelijk account te krijgen zal je schriftelijke toestemming moeten krijgen van een aantal mensen, oplopend in de hiërarchie. De aanvraag zal nauwkeurig bekeken moeten worden. Hij zal moeten voldoen aan een aantal standaard criteria voordat er een beslissing kan worden genomen om de aanvraag goed te keuren of niet. Dit zal bijvoorbeeld afhangen van wat je van plan bent te doen, of het om een test of productieomgeving gaat, jouw rol, hoe lang je toegang nodig hebt, de vertrouwelijkheids-, integriteits- en beschikbaarheidseisen van de data, hoe kritiek de applicatie is, enzovoort.

Verder zal dit een tijdelijk account zijn, het zal ophouden te bestaan na een bepaalde periode of als je klaar bent met jouw werkzaamheden (als je weer bent uitgelogd). Dus als je het daarna nog een keer nodig hebt, zal je het opnieuw moeten aanvragen. En opnieuw. En opnieuw. En uiteraard worden ook hier alle acties die met dit account plaatsvinden gemonitord en vastgelegd. Het is daarmee weliswaar een veilige, maar o zo moeilijke manier om toegang te verkrijgen.

Nu gerust slapen?

Dit is uiteindelijk wat het bedrijf zou moeten willen bereiken. De sleutels van het Koninkrijk en de daarbij behorende Superkrachten zijn veilig. We weten wie de Superkrachten hebben en wat ze er mee doen en wanneer ze het hebben gedaan.  Kunnen we nu lekker slapen? In ieder geval beter! Waakzaamheid blijft echter geboden! Misbruik zit in een klein hoekje. Maar dat is voor een volgende blog.

Over de auteur

arend-jan-buzepol-cybersecurity

Arend-Jan Buzepol

Director Consulting Expert a.i.

Arend-Jan is sinds 1997 werkzaam bij CGI en is expert op het gebied van Identity & Access Management (IAM). Hij is een Certified Information Security Manager (CISM) en heeft onder andere als Product Owner bijgedragen aan het succes van diverse security oplossingen. Deze oplossingen hadden ...

Voeg commentaar toe

Comment editor

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
Blog richtlijnen en gebruiksvoorwaarden