Inzicht in IT-security

Ruim een jaar geleden wijdde Alberto Stegeman een uitzending aan de veiligheid van de rechtbank in Utrecht. Het was hem gelukt om met behulp van een Rijkspas en voorzien van een nepwapen de rechtbank van Utrecht binnen te komen. De Rijkspas had hij kunnen bemachtigen via een oud-medewerker van de rechtbank. Blijkbaar werkte de pas gewoon nog op de toegangspoorten van het gebouw. Veel organisaties zijn zich inmiddels bewust van de gaten, die kunnen ontstaan in hun beveiliging, zowel op fysiek als logisch niveau. Daarom is het zogenaamde ‘ethisch hacken’ momenteel hip.

Hacken bestaat in vele vormen. Vaak is het doel van hacken om schade aan te richten, maar voor ‘ethisch hacken’ geldt dat niet. De doelstelling van ethisch hacken is juist om de kans op schade te beperken. Bij ethisch hacken worden alle systemen en de netwerkinfrastructuur binnen een organisatie onderzocht op eventuele beveiligingsfouten. Gevonden fouten worden niet misbruikt, maar worden aan de verantwoordelijke afdeling doorgegeven, zodat ze direct opgelost kunnen worden. De nadruk ligt dus op IT-security. Veel grote accountancykantoren hebben inmiddels een team hackers in dienst, die bij organisaties deze beveiligingsfouten opsporen. Maar er zijn ook al succesvolle bedrijven die zich toeleggen op het vinden van beveiligingslekken in systemen, zoals het Amerikaans-Nederlandse bedrijf HackerOne. HackerOne hanteert een model voor het vinden van beveiligingsproblemen dat eerder al door grote bedrijven als Google en Microsoft werd gebruikt. Dit zijn de zogeheten bug bounty programs, waarbij hackers worden beloond wanneer zij gaten in de beveiliging van software ontdekken en deze netjes melden. De startup maakt gebruik van duizenden hackers, die bugs kunnen melden over publiek toegankelijke sites en breed gebruikte internetsoftware. Bij commerciële software vraagt HackerOne een commissie van 20 procent op het bedrag dat een bedrijf aan een zogeheten whitehat-hacker betaalt voor een bugmelding.

 User lifecycle
Voor veel organisaties geldt dat zij van buiten het netwerk vrij lastig te hacken zijn, maar wanneer de boosdoener zich binnen de muren van de organisatie bevindt is het heel eenvoudig om schade aan te richten. Wanneer bijvoorbeeld een ex-medewerker nog beschikt over een pas voor fysieke toegang, weet binnen te komen en met een netwerkkabel zijn computer aansluit, dan is het vrij eenvoudig om gevoelige informatie achterover te drukken. Of anderszins kwaad te doen, zoals in het voorbeeld van Alberto Stegeman. Er zijn legio van dit soort voorbeelden uit de praktijk. Denk bijvoorbeeld aan (catering)medewerkers, die vliegtuigen op Schiphol bevoorraden. Het personeelsbestand van dit soort bedrijven is vaak sterk wisselend en bestaat voornamelijk uit vakantie- en uitzendkrachten. Daarom is het zeer belangrijk om de fysieke toegang tot de landingsbaan sterk te reguleren en te automatiseren, zodat de veiligheid van passagiers gegarandeerd is. Zoals het voorbeeld aangeeft, ontstaan de meeste beveiligingsfouten in het user lifecycle proces van een medewerker en dan met name bij transfers, dus wanneer medewerkers wijzigen van functie of locatie.

Het user lifecycle proces omvat alle stappen, die een user account van een medewerker in de organisatie doorloopt. Iedere stap heeft consequenties voor de autorisaties, die een medewerker heeft. De eerste stap is het aanmaken van een user account (creëren van een digitale identiteit), wanneer de medewerker in dienst komt, zodat de medewerker toegang heeft tot het netwerk en applicaties. Voor fysieke toegang wordt een toegangspas of toegang tot bijvoorbeeld een sleutelkast verstrekt. De medewerker kan dan aan de slag in zijn eerste functie. Maar wanneer de medewerker promotie maakt, moeten de instellingen worden gewijzigd, omdat de medewerker andere (of meer) autorisaties nodig heeft. Tot slot moet het user account worden ontmanteld en uiteindelijk verwijderd worden, wanneer de medewerker uit dienst treedt. Heel soms dient een user account weer geactiveerd te worden, wanneer een medewerker terugkomt.

 Accumulatie van rechten
Bij het indienstproces worden bepaalde autorisaties toegewezen aan een medewerker. In de meeste gevallen worden daarbij dezelfde rechten gegeven als een medewerker in een soortgelijke functie, de zogenaamde voorbeeldgebruiker. Bij het kopiëren van de rechten van een voorbeeldgebruiker kan het gebeuren dat de nieuwe medewerker in eerste instantie teveel rechten krijgt, omdat de voorbeeldgebruiker in het verleden bijvoorbeeld een keer aan een bepaald project heeft gewerkt en daarvoor specifieke rechten heeft verkregen. Dit geeft echter niet veel problemen, omdat de nieuwe medewerker vaak niet weet dat hij die ‘extra’ rechten bezit. Waar het misgaat, is als medewerkers naar een andere afdeling of locatie verhuizen of een andere functie krijgen, de zogenaamde ‘transfers’. De nieuwe, benodigde autorisaties, die nodig zijn in de nieuwe functie, worden dan toegekend en de ‘oude’ rechten worden niet afgenomen. Medewerkers geven bijvoorbeeld aan dat zij graag nog even gebruik willen maken van de oude rechten om bepaalde zaken af te ronden. Uiteindelijk wordt dat “even” dan voor altijd. En de IT-afdeling, die de rechten zou moeten ontnemen, wordt daarvan namelijk niet (of te laat) op de hoogte gebracht. Daardoor ontstaat een accumulatie van rechten.

 Andere houding
Die opstapeling van rechten is onzichtbaar voor de organisatie, omdat binnen de organisatie (managers, directie) niemand volledige inzage heeft in welke autorisaties medewerkers hebben vóór en ook ná een transfer. De organisatie heeft geen weet van wie welke autorisaties heeft en vraagt er ook niet naar. Voor hen is het enkel van belang dat een medewerker zijn werk kan doen en productief is. De IT-afdeling weet uit ervaring wel ongeveer wie welke rechten heeft en nodig heeft. Maar door drukte en miscommunicatie voegen zij enkel rechten toe (dan hebben zij in ieder geval voldaan aan de vraag) en nemen zij geen rechten af. De organisatie zou een andere houding aan moeten nemen en veel beter in controle moeten zijn over welke autorisaties medewerkers hebben en welke autorisaties zij zouden moeten hebben om hun werk te kunnen doen. Daardoor is de kans op beveiligingsfouten kleiner. Een Identity Management oplossing kan hierin faciliteren.

 Identity Management & Access Governance
Een manier om de kans op beveiligingsfouten te beperken, is door de inzet van Access Governance. Met een geautomatiseerde oplossing voor Access Governance is het mogelijk om ervoor te zorgen dat medewerkers de juiste middelen (toegangsrechten, toegang tot applicaties, faciliteiten zoals een laptop, smartphone, etc) hebben om hun werkzaamheden te kunnen uitvoeren. Er worden precies de juiste middelen toegekend, wanneer een nieuwe medewerker in dienst treedt. Niet teveel en niet te weinig. Om Access Governance toe te kunnen passen, is het nodig om een zogenaamd rollenmodel op te stellen. Het doel van dit rollenmodel is om aan te geven welke middelen een medewerker nodig heeft om bepaalde werkzaamheden uit te kunnen voeren. Het model bestaat uit twee delen, namelijk de definitie van de werkzaamheden en de middelen, die vanuit het netwerk of facilitymanagement worden aangeboden. De verbinding tussen de twee delen van het rollenmodel bepaalt welke middelen aan werkzaamheden verbonden zijn (zie figuur 1).

 Rollenmodel
Het rollenmodel bestaat aan de linkerkant uit een logische groepering van werkzaamheden, die binnen een bepaalde afdeling worden uitgevoerd. Dit deel van het model wordt opgezet en beheerd door medewerkers, die goed op de hoogte zijn van welke werkzaamheden binnen een onderdeel van de organisatie worden uitgevoerd. Dit zijn veelal informatie- en securitymanagers in samenspraak met de afdelingsmanagers. Een voorbeeld van een groepering van werkzaamheden:

OU: Financiële afdeling

a.            BR: Bijhouden grootboek
b.            BR: Uitvoeren betalingen
c.            BR: Debiteurenbeheer
d.            BR: Opstellen Rapportages

Het rollenmodel bestaat aan de rechterkant uit een logische groepering van (technische) middelen. Dit deel van het model wordt opgezet en beheerd door technische medewerkers en zijn meestal lid van de afdeling automatisering. Dit zijn functioneel applicatiebeheerders, systeembeheerders en/of facilitymedewerkers. Voorbeelden van technische groeperingen:

1.            ITR: Betaling facturen

a.            Permissie: groepslidmaatschap AD GRP_APPL_SAP_FICO
b.            Permissie: Profiel SAP FICO_BASIC
c.            Permissie: Profiel SAP FICO_INVOICE_LVL2

Wanneer een medewerker in dienst komt, wordt hij opgevoerd in een HR-systeem en dankzij user provisioning (functionaliteit van een Identity Management systeem) wordt automatisch een netwerkaccount voor de medewerker aangemaakt. De Identity Management software leest daarvoor het rollenmodel, dat gecreëerd is met Acces Governance uit en weet precies welke middelen moeten worden toegekend aan het account. De voordelen worden groter als Access Governance ook wordt toegepast als een medewerker van functie, afdeling of locatie wisselt en/of uit dienst treedt.

Door de inzet van Access Governance wordt voorkomen dat iemand iets teveel of te lang mag binnen het netwerk. Een medewerker kan alleen schade aanrichten binnen de rol, die hij vervult en niet daarbuiten.

Door het Identity management systeem vervolgens te koppelen aan een pasjessysteem kan naast de logische toegang ook de fysieke toegang automatisch worden geregeld. Want ook het toekennen van toegang tot fysieke ruimtes is in feite een onderdeel van de user lifecycle van een medewerker. De uitgifte van een toegangspas en de toegankelijke ruimtes worden daarbij ook gekoppeld aan de functie/rol van een medewerker. Zo kan een medewerker nooit toegang krijgen tot een locatie waar hij/zij (op die dag) niet werkt. Dit is vrij gebruikelijk bij zorginstellingen, waar verplegend personeel de ene dag op de ene locatie werkt en de andere dag op een andere locatie.  

Schade beperken
Als er, ondanks alle maatregelen, toch schade aangericht wordt, kan een Identity Manager ook helpen de schade zoveel mogelijk te beperken. Middels een selfservice portal kunnen managers de mogelijkheid krijgen om per direct autorisaties van medewerkers te ontnemen. Dat kan bijvoorbeeld nodig zijn, wanneer medewerkers op staande voet worden ontslagen. Dit wordt bij sommige organisaties ook wel ‘Emergency Offboarding’ genoemd. In deze gevallen is het ontslagproces zo abrupt, dat het ontnemen van de rechten niet via het normale bedrijfsproces kan lopen; te weten door de afdeling personeelszaken aangeduid in het HR-systeem en vervolgens via provisioning wordt het user account gedeactiveerd. Het ontslag is té urgent en daarom heeft de organisatie de mogelijkheid om met één druk op de knop de rechten te ontnemen. Eventueel kan een workflow worden ingesteld, waardoor een security officer nog een laatste goedkeuring zou kunnen geven, alvorens het account in alle applicaties en ook fysieke toegang wordt geblokkeerd. Ook kan er worden ingesteld dat het account niet zonder goedkeuring van een security officer weer geactiveerd kan worden en dat de medewerker niet zomaar weer in dienst kan treden.

 Conclusie

Met ethisch hacken kunnen beveiligingsgaten worden opgespoord. Een Identity Manager in combinatie met Access Governance kan helpen om proactief beveiligingsfouten te voorkomen en eventueel de schade zoveel mogelijk te beperken. Geconfronteerd worden met fouten is natuurlijk nooit fijn, maar wel belangrijk om de privacy en de veiligheid van gegevens te garanderen.

Wanneer er wordt gezocht naar open source Identity Management oplossingen, dan zijn er diverse leveranciers er te vinden. Enkele voorbeelden daarvan zijn: Apache Syncope, OpenLDAP, OpenIAM, midPoint, OpenRegistry, Atricore en Shibboleth. In de praktijk blijkt dat veel Identity Management leveranciers in Nederland niet of nauwelijks vertegenwoordigd zijn. Er zijn vaak maar 1 à 2 architecten, die voldoende kennis hebben om een implementatie succesvol te begeleiden. In het geval van een open source variant ben je als organisatie zelfs volledig aangewezen op de community, forums etc. Er is geen partij die ondersteuning biedt bij eventuele problemen. Dit zou een overweging moeten zijn bij je keuze voor een Identity Management oplossing.