We hebben het bij cyberaanvallen over zwakke plekken, aanvalsvectoren en achterdeurtjes. Een element komt in de beschouwingen over security spaarzaam aan bod: gebruikersrechten. Met als grootste omissie die ene persoon met alle rechten.
Veel hacks zijn succesvol. Niet omdat iemands computer gecompromitteerd wordt, maar omdat het gehackte device direct toegang geeft tot een veelheid aan systemen. Anders, er ontstaan problemen omdat een gebruiker te veel rechten heeft.
Bij veel bedrijven is deze situatie in de loop der tijd ontstaan, omdat het nodig was dat een (it-) medewerker voor een project of incident toegang nodig had tot bepaalde systemen of tools en dit toch wel érg handig bleek. Ook kan het voorkomen dat medewerkers binnen hun organisatie wisselen van functie, en hun gebruiksauthorisaties meenemen naar hun nieuwe rol.
Grip
Het is goed om stil te staan bij de mogelijkheden die een organisatie heeft om meer grip te krijgen op de rechten van de gebruikers. Een optie is om een nulmeting te doen op alle werknemers en te beoordelen of ze alle applicaties, tools en data nog wel nodig hebben in hun huidige functie. Houdt hierbij het absoluut benodigde minimum aan.
Overweeg daarbij om een rbac-systeem in te richten, waarbij de gebruiksautorisaties gekoppeld worden aan functionele rollen. Hierdoor hoef je deze niet voor iedere individuele werknemer apart in te richten en verklein je de kans op fouten bij rechtentoewijzing. Tegelijkertijd voldoe je aan wet- en regelgeving op het gebied van privacy en informatiebeveiliging. Door daarnaast in gesprek te gaan met je softwareleveranciers, kun je uitvinden welke rollen hun applicaties bieden en deze vervolgens toepassen. Voer minimaal eens per jaar een audit uit en pas de rollen aan, wanneer dit nodig is.
Andere inlogcode
Daarbij is het evident dat één persoon binnen een organisatie meerdere rollen kan vervullen. Zo is een netwerkbeheerder ook een gebruiker van Office en zou hij voor beide rollen een ander account en een andere inlogcode moeten hebben. Deze ontkoppeling betekent ook dat er geen beheer rechtstreeks vanaf een werkstation moet worden gedaan. Houd hiervoor een externe server met een separate autorisatie aan.
Door deze scheiding blijft de schade bij een aanval vaak relatief beperkt. Het segmenteren van de infrastructuur, de applicaties en onderliggende systemen is sowieso een goed idee. Om in de netwerkanalogie te blijven; er kunnen verschillende vlan’s naast elkaar draaien, zonder dat ze elkaar zien of last van elkaar hebben. Dat is op beveiligingsvlak pure winst.
Om hierop grip te krijgen, is een configuration management database (cmdb) een uitstekende, zij het bewerkelijke oplossing. Een cmdb is een repository met informatie over de it-omgeving, de componenten die gebruikt worden voor de levering van it-diensten. Het is zaak deze cmdb vooral pragmatisch aan te pakken om te voorkomen dat er een administratieve draak ontstaat, die zijn doel voorbijschiet. Voor kleine organisaties zou zelfs een Excel-sheet volstaan; het gaat er vooral om dat de informatie actueel gehouden wordt.
Het voordeel van een cmdb of vergelijkbaar overzicht is dat wanneer er bijvoorbeeld een encryptie-aanval wordt gesignaleerd, je direct kun achterhalen waar deze vandaan komt, wie er bij betrokken zijn en waar deze heengaat om gericht actie te ondernemen om de aanval de pas af te snijden. Heb je dat overzicht niet, dan is elke cyberthreatdetectie-functionaliteit nutteloos en kun je niets anders doen dan de aanval uitzitten en achteraf puinruimen.
Calamiteit
Mocht zich ondanks alle maatregelen toch een calamiteit voordoen, dan heeft de hierboven beschreven aanpak als voordeel dat het aantal getroffen systemen relatief beperkt zal zijn. Daarnaast is er vrij snel een overzicht beschikbaar van de getroffen onderdelen en wie hiervoor verantwoordelijk zijn, zodat bijvoorbeeld de incidentmanager deze medewerkers kan samenbrengen om te bepalen hoe het herstel eruit gaat zien. Dat kan variëren van een ‘simpele’ failover tot systeemherstel vanuit een backup of zelfs de data terughalen vanuit een ge-airgapte datavault. Op deze manier wordt de recovery op elk vlak goed ingeregeld.
Gelukkig is de tijd voorbij dat één persoon de sleutels had van de fabriek. In it-termen: de god-account is niet meer, amen.
Goed en helder artikel, Egon. Helaas is de strekking gelijk aan artikelen over beheer in de beginjaren van ITILen is nog steeds het actueel. Weliswaar komen we zeer zelden problemen tegen door onhandig gebruik van een superuser account van een collega. Maar de erkenning om stringent met een autorisatiesysteem te werken, is niet altijd even groot. Geitenpaadjes bij het beheer van professionele systemen komen voor en kunnen zorgen voor bijvoorbeeld het door elkaar lopen van identiteitenbeheer en autorisatiebeheer, bij het toepassen van RBAC of ABAC, et cetera. Er zijn vaak verouderde privileges, ook bij ICT-bedrijven. Dat is geen ICT-probleem, maar een organisatieprobleem gekoppeld aan ICT.
In de basis kan ik me wel vinden in het artikel, maar ik mis bij dit soort artikelen vaak de praktische kant van het verhaal. In sommige rollen betekend te geschetste aanpak dat je als medewerker constant moet nadenken met welk account je op welke machine iets moet gaan doen (kijkend naar één van mijn rollen in het verleden: oa. gebruiker, admin voor een aantal applicaties, admin op een aantal servers, rechten om testsystemen (fysieke machines met zowel embedded als user software) te installeren, rechten om testsystemen te bedienen)
Met 1 à 2 accounts kunnen werken is dan toch wel heel handig
Als gebruiker met beperkte rechten (least priviliges) kun je een taak met verhoogde laten uitvoeren, het probleem van god-accounts zit dan ook meer in de services accounts. Wat betreft de zwakke plekken, aanvalsvectoren en achterdeurtjes wisselen de wachtwoorden van deze accounts niet regelmatig.