Door: Gerwin, Security Architect/Consultant

Een praktijkgeval Privileged Identity Management

De hack van de Franse TV zender TV5 door ISIS sympathisanten heeft veel aandacht gekregen in de media. Aanvankelijk was er verbazing over hoe de ‘goed beveiligde’ zender hierdoor verrast kon worden, maar al snel bleek dat de wachtwoorden van YouTube, Instagram en Twitter, en waarschijnlijk ook andere wachtwoorden, voor iedereen zichtbaar op de redactie hingen. In een TV interview over de hack zijn ze zelfs in beeld te zien (zie http://arstechnica.com/security/2015/04/hacked-french-network-exposed-its-own-passwords-during-tv-interview/ voor meer details)

Uit het feit dat deze wachtwoorden op het prikbord hingen kan opgemaakt worden dat meerdere mensen op de redactie deze gegevens blijkbaar nodig hadden voor hun dagelijks werk. Dit incident is een voorbeeld van het risico dat gedeelde accounts, al dan niet met vergaande privileges, kunnen vormen als ze niet op de juiste manier beheerd worden.

Het probleem
Administratieve of ‘privileged’ accounts zijn bij elk bedrijf noodzakelijk om de IT systemen te kunnen beheren. Traditioneel wordt dit vaak op één van de volgende manieren opgelost

1. Elke beheerder krijgt een persoonlijke beheer account

Hoewel hiermee elke beheerder verantwoordelijk gemaakt kan worden voor zijn eigen account, en dus ook zijn individuele acties gecontroleerd kunnen worden, heeft deze benadering de volgende nadelen:

• het leidt tot een exponentiele toename van accounts met verhoogde autorisaties (aantal beheerders x aantal systemen).
• het risico van fouten in de toekenning en intrekking van deze rechten neemt met dit aantal evenredig toe. Wat als de medewerker vertrekt, en één van de beheeraccounts niet wordt ingetrokken?
• het risico bestaat dat de beheerder voor alle accounts hetzelfde wachtwoord gaat gebruiken.
• Sommige accounts kunnen niet gepersonaliseerd worden, zoals de ‘root’ account op Unix, ‘sys’ of ‘system’ in Oracle databases of ‘administrator’ in Windows. Van deze accounts bestaat er altijd maar 1 per systeem
• hogere beheerkosten vanwege het grotere aantal accounts en de bijbehorende rechten die gecontroleerd moeten worden.

2. Gedeelde privileged accounts

Deze benadering kent niet de nadelen die hierboven beschreven zijn, maar hiermee zijn weer andere problemen gemoeid

• het is niet meer te traceren wie verantwoordelijk is voor acties die onder het account zijn uitgevoerd. Het kan immers iedereen die toegang had tot het account geweest zijn, inclusief de hackers.
• Alle gebruikers moeten het wachtwoord kennen, en bij het wijzigen moeten alle gebruikers hiervan op de hoogte gesteld worden; de wachtwoorden worden daarom vaak in een centrale spreadsheet opgeslagen, of in het ergste geval op een prikbord gehangen. Een andere, omslachtige manier is het bewaren van de wachtwoorden in verzegelde enveloppen in een kluis, met alle logistieke problemen van dien (denk aan geografisch verspreid liggende locaties).

De oplossing: Privileged Identity Management (PIM)
Een goede Privileged Identity Management oplossing biedt onder andere de volgende functionaliteit:

1. een manier om gebruikersnamen en wachtwoorden (credentials) veilig op te slaan in een digitale wachtwoordkluis of ‘vault’, zodat ze niet door ongeautoriseerde gebruikers gebruikt kunnen worden. Dit vervangt de onveilige spreadsheet, het prikbord of de fysieke kluis.
2. een manier om deze wachtwoorden veilig te kunnen gebruiken, door een ‘checkout’ mechanisme. Als een gebruiker nu een privileged account wil gebruiken haalt hij dit op uit het PIM systeem, waarbij het gebruik meteen geregistreerd wordt (wie, van wanneer tot wanneer, waarom (bv. Helpdesk ticket)). Voorafgaand aan het gebruik kan het PIM systeem een goedkeuring vereisen (4-ogen principe).
3. Optioneel een Single Sign On mechanisme, waardoor de gebruiker het wachtwoord niet meer te zien krijgt of moet kopiëren, maar transparant wordt aangelogd op het doelsysteem.
4. Een auditing component die gebruik van de credentials vastgelegd, optioneel aangevuld met session recording, die ook de gebruikte commando’s of acties registreert.
5. De mogelijkheid om wachtwoorden periodiek automatisch te wijzigen.

Daarnaast zijn er vaak mogelijkheiden om applicatieve accounts te integreren (zodat wachtwoorden niet meer in propertiefiles hoeven worden opgeslagen), en multi-factor authenticatie in te stellen, zodat sterke authenticatie ook kan worden afgedwongen voor systemen die dit niet ondersteunen.

SecurIT werkt voor Privileged Identity Manager oplossingen samen met twee Business Partners, Cyber-Ark en IBM. CyberArk is een speler die al jarenlang volledig gericht is op het bieden van PIM oplossingen en loopt voorop in de nieuwste ontwikkelingen. IBM heeft nog niet zo lang een volwaardige PIM oplossing, maar met de introductie van de laatste versie van de PIM appliance hebben ze hun uitgebreide Security portfolio nog vollediger gemaakt.
Beide producten ontlopen elkaar niet veel, en hebben alle hierboven genoemde functionaliteit in meerdere of mindere mate aan boord, in de tabel hieronder worden de belangrijkste verschillen kort genoemd

Waar Cyber-Ark zich erop richt de beste oplossing en de nieuwste features te bieden, focust IBM meer op het geheel, door de integratie met bestaande producten en processen (hoewel de IBM appliance ook als standalone oplossing kan werken). Welke oplossing het beste bij een klant past, hangt van de specifieke eisen en wensen af.