Geloof niet in het god-account




We hebben het bij cyberaanvallen over zwakke plekken, aanvalsvectoren en achterdeurtjes. Een aspect komt in de beschouwingen over safety spaarzaam aan bod: gebruikersrechten. Met als grootste omissie die ene persoon met alle rechten.

Veel hacks zijn succesvol. Niet omdat iemands laptop gecompromitteerd wordt, maar omdat het gehackte gadget 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 mission of incident toegang nodig had tot bepaalde systemen of instruments 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

“Een optie is om een nulmeting te doen op alle werknemers en te beoordelen of ze alle applicaties, instruments en information nog wel nodig hebben in hun huidige functie”

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, instruments en information nog wel nodig hebben in hun huidige functie. Houdt hierbij het absoluut benodigde minimal 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 aside 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 Workplace 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 final van elkaar hebben. Dat is op beveiligingsvlak pure winst.

Om hierop grip te krijgen, is een configuration administration 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

“Gelukkig is de tijd voorbij dat één persoon de sleutels had van de fabriek”

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 information terughalen vanuit een ge-airgapte datavault. Op deze manier wordt de restoration 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.

Laat een reactie achter

Scroll naar boven