Artikel

Inzicht in IT Security met ethisch hacken

Ruim een jaar geleden wijdde Alberto Stegeman een uitzending aan de veiligheid van de rechtbank in Utrecht. Het was hem gelukt om, voorzien van een nepwapen, met behulp van een Rijkspas 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 veel 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 door grote bedrijven als Google en Microsoft werd gebruikt: zogeheten bug bounty programs, waarbij hackers worden beloond wanneer zij gaten in de beveiliging van software ontdekken en deze netjes melden. De start-up 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 een ex-medewerker bijvoorbeeld nog beschikt over een pas voor fysieke toegang, weet binnen te komen en met een netwerkkabel zijn computer aansluit, 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 medewerkers die vliegtuigen op Schiphol bevoorraden (catering etc). 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 sterkt te reguleren en te automatiseren, zodat de veiligheid van passagiers gegarandeerd is. Zoals het voorbeeld aangeeft, ontstaan de meeste beveiligingsfouten in het user life cycle proces van een medewerker en dan met name bij transfers, ofwel 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 verkregen of toegang tot bijvoorbeeld een sleutelkast. De medewerkers kan 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. En tot slot moet het user account worden ontmanteld en uiteindelijk verwijderd wanneer de medewerker uit dienst treedt. Heel soms dient een user account weer geactiveerd te worden wanneer een medewerker herintreedt.

Accumulatie van rechten
Bij het indienst proces 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 te veel 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 mis gaat, is als medewerkers naar een andere afdeling of locatie verhuizen of een andere functie krijgen, de zogenaamde ‘transfers’. De nieuw benodigde autorisaties worden dan toegekend die nodig zijn in de nieuwe functie en worden ‘oude’ rechten niet afgenomen. Medewerkers geven bijvoorbeeld aan dat zij graag nog eventjes gebruik willen maken van de oude rechten om nog zaken af te ronden. Uiteindelijk wordt dat eventjes 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 voor en ook na 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 onder andere 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 wat 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 te veel en niet te weinig. Om Access Governance toe te kunnen passen, is het nodig een zogenaamd rollenmodel op te stellen. Het doel van het 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 facility management 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/security managers 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 facility medewerkers. 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 wat 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 te veel of te lang mag in 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 zo veel mogelijk te beperken. Middels een self-service 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, 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 te 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.

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

Categorie:   
Auteur(s)
afbeelding van tseinen
Tjeerd Seinen
Tools4ever - Technisch Account Manager

Tjeerd Seinen als account manager werkzaam bij Tools4ever in Nederland. Hij beschikt over zowel een technische als commerciële achtergrond en hij is daardoor in staat om kansen in de markt om te zetten in functionaliteiten voor producten en consultancy diensten. Tjeerd heeft meer dan 20 jaar ervaring op het gebied van sales en softwareontwikkeling. Hij studeerde technische informatica aan de Hogeschool van Amsterdam. Daarnaast rondde hij de MBA-opleiding van het NIMBAS in Utrecht met succes af.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.