Logische Toegangsbeveiliging Project risico’s bij RBAC implementaties

Afstudeerscriptie I. Bierman W. van der Valk Begeleiders B. Bokhorst E. van Essen Datum April, 2007 Plaats Amsterdam

IT-Auditing vrije Universiteit Amsterdam 2/25

Voorwoord

Deze scriptie is geschreven in het kader van de afronding van de post doctorale opleiding IT-auditing aan de vrije Universiteit te Amsterdam.

Tijdens onze dagelijkse werkzaamheden als IT-auditor komen we regelmatig in aanraking met risico’s en maatregelen die betrekking hebben op de rechten van gebruikers in IT-systemen. We werken allebei bij Deloitte als ERP specialist en hebben het plan om dieper in te gaan op het gebruikers- en autorisatievraagstuk. Uiteindelijk hebben we het onderwerp nog wat breder getrokken dan ERP systemen en zijn we ingegaan op de wijze waarop Logische Toegangsbeveiliging (LTB) projecten worden aangepakt. Het resultaat van ons onderzoek ligt voor u.

Net als bij LTB-projecten is ook bij ons onderzoek duidelijk geworden dat het niet eenvoudig is om de scope van je onderzoek te beheersen. Door de vele discussies is het onderwerp een aantal keren flink omgegooid. Ondanks de kleine vertraging hebben we ons onderzoek gelukkig succesvol kunnen afronden.

Onze dank gaat uit naar iedereen die geholpen heeft bij de totstandkoming van het onderzoek. Een persoonlijk woord van dank voor onze scriptiebegeleider Bart Bokhorst en Ed van Essen voor hun bijdrage aan ons afstuderen.

Drs. Ivo Bierman Drs. Willem van der Valk

IT-Auditing vrije Universiteit Amsterdam 3/25

Managementsamenvatting

In de afgelopen jaren zijn bedrijven intensiever gebruik gaan maken van IT-systemen. Steeds meer systemen worden aan elkaar gekoppeld en steeds meer activiteiten worden geautomatiseerd. Doordat het gebruik van IT-systemen gegroeid is, is er ook een grotere behoefte ontstaan naar adequate toegangsbeveiliging tot de systemen. Gezien de toename in complexiteit van de IT-systemen blijkt het inrichten van goede logische toegangsbeveiliging geen eenvoudige klus. Veel organisaties willen de Logische Toegangsbeveiliging (LTB) verbeteren en starten hiervoor projecten op.

In de praktijk blijkt dat het lastig is om LTB-projecten succesvol te laten zijn. Met het onderzoek willen we nagaan waarom dit zo is. Op basis van een risicoanalyse zijn aanbevelingen opgesteld ter verbetering.

Bij de start van het onderzoek hadden we de indruk dat bij het uitvoeren van Logische Toegangsbeveiliging projecten niet alle relevante gebieden in voldoende mate worden meegenomen. Om dit inzichtelijk te maken hebben we een conceptueel model opgesteld waarmee de positie van een LTB-project binnen een organisatie te beschrijven is (zie figuur rechts).

Voor het identificeren van risico’s zijn interviews gehouden met RBAC experts. Tijdens de interviews is een volledige RBAC projectcyclus doorlopen. Deze risico’s hebben we met behulp van het conceptueel model geanalyseerd. Uit de analyse van de projectrisico’s hebben we de volgende conclusies kunnen trekken:

• De nadruk ligt te veel op de rechterzijde van het conceptueel model. LTB-projecten worden vaak gestuurd door IT-management en te weinig door de business.

• De scope van een LTB-project wordt niet adequaat beheerst. Het starten met een beheersbare scope is essentieel voor het succes van het LTB-project. Het kiezen van een goede uitrolstrategie is hierbij van belang.

• In de praktijk blijk het realiseren van een goede overdracht van de project- naar de beheerorganisatie niet eenvoudig. In het conceptueel model is dit het evenwicht tussen de boven- en de onderzijde.

Met behulp van het model is aangetoond dat de positionering van een project in de organisatie een belangrijke oorzaak is van de risico’s bij LTB-projecten. Het opgestelde conceptueel model blijkt nuttig te zijn om risico’s bij LTB-projecten te analyseren.

IT-Auditing vrije Universiteit Amsterdam 4/25

Inhoudsopgave

1 Inleiding 5

1.1 Probleemstelling 5

2 Logische Toegangsbeveiliging 7

2.1 Definitie Logische Toegangsbeveiliging 7

2.2 Redenen voor verbetering 7

2.3 Conceptueel model Logische Toegangsbeveiliging 9

3 Role Based Access Control (RBAC) 12

3.1 Theorie 12

3.2 Ontwikkelingen 12

3.3 Techniek 13

3.4 Projectfasen 14

4 Risico identificatie 17

4.1 Ambitieuze scope 17

4.2 Onevenwichtig projectteam 17

4.3 Complicaties door IT systemen 17

4.4 Veranderende omgeving 18

4.5 Verkeerde uitrolstrategie 18

4.6 Ontbreken testomgeving 18

4.7 Ontbreken beheerproces 19

5 Risicoanalyse en aanbevelingen 20

5.1 Ambitieuze scope 20

5.2 Onevenwichtig projectteam 20

5.3 Beperkingen IT systemen 20

5.4 Veranderende omgeving 21

5.5 Verkeerde uitrolstrategie 21

5.6 Ontbreken testomgeving 21

5.7 Ontbreken beheerproces 22

6 Evaluatie Model 23

7 Conclusie 24

8 Literatuurlijst 25

8.1 RBAC Artikelen 25

8.2 Overige literatuur 25

IT-Auditing vrije Universiteit Amsterdam 5/25

1 Inleiding

Grote organisaties steunen sterk op applicaties om de bedrijfsprocessen efficiënt en betrouwbaar te laten verlopen. Door deze afhankelijkheid van IT systemen is het van belang dat de systemen goed blijven functioneren. Een van de maatregelen om het goed functioneren van de IT systemen te waarborgen is het toekennen van specifieke autorisaties aan gebruikers. Als een medewerker alleen toegang heeft tot gegevens en transacties die nodig zijn voor zijn of haar werkzaamheden, dan loopt de organisatie minder risico dat de beschikbaarheid, vertrouwelijkheid of integriteit van de applicatie wordt gecorrumpeerd. Het inrichten van de gebruikersstructuur en rechten in een IT omgeving wordt ook wel Logische Toegangsbeveiliging (LTB) genoemd. In de praktijk blijkt het implementeren van Logische Toegangsbeveiliging een risicovol project te zijn.

1.1 Probleemstelling

Het doel van het onderzoek is het analyseren waarom LTB-projecten vaak niet succesvol zijn. Het is de bedoeling om op basis van een risicoanalyse aanbevelingen op te stellen ter verbetering. Voor het onderzoek is de volgende vraagstelling gedefinieerd:

“Welke risico’s spelen bij Logische Toegangsbeveiliging projecten, waar worden de risico’s

door veroorzaakt en welke verbeteringen zijn mogelijk om de risico’s te beheersen”

Om tot een antwoord te komen op de vraagstelling hebben we de volgende deelvragen gedefinieerd:

1. Wat is Logische Toegangsbeveiliging? 2. Hoe ziet een Logische Toegangsbeveiliging project eruit? 3. Welke risico’s zijn te identificeren bij Logische Toegangsbeveiliging projecten? 4. Waardoor ontstaan de risico’s bij Logische Toegangsbeveiliging projecten? 5. Welke verbeteringen zijn mogelijk om de risico’s bij Logische Toegangsbeveiliging

projecten te beheersen?

In hoofdstuk 2 komen we tot een definitie van Logische Toegangsbeveiliging. Tevens gaan we in op de redenen waarom projecten worden gestart ter verbetering van de Logische Toegangsbeveiliging. Aan het einde van het hoofdstuk is een conceptueel model opgesteld. Dit conceptueel model beschrijft de manier waarop we kijken naar het concept Logische Toegangsbeveiliging.

In hoofdstuk 3 wordt antwoord gegeven op de vraag hoe een LTB-project er uit ziet, waarbij een RBAC project als concreet voorbeeld is gekozen. Hierbij wordt uitgelegd wat RBAC is en hoe een RBAC project er op hoofdlijnen uit ziet.

In hoofdstuk 4 staan de risico’s beschreven die we tijdens de interviews met RBAC specialisten hebben geïdentificeerd. Deze risico’s worden in hoofdstuk 5 geanalyseerd met

IT-Auditing vrije Universiteit Amsterdam 6/25

behulp van het conceptueel model. Hierbij worden er aanbevelingen gedaan om de risico’s bij LTB-projecten te beheersen.

In hoofdstuk 6 wordt het opgestelde conceptueel model geëvalueerd. Tot slot staan in hoofdstuk 7 de conclusies van ons onderzoek.

IT-Auditing vrije Universiteit Amsterdam 7/25

2 Logische Toegangsbeveiliging

Doordat informatie een steeds belangrijkere rol speelt in bedrijfsprocessen heeft ook de beveiliging van de informatie een hogere prioriteit gekregen. Om te kunnen overleven is het voor een organisatie van belang dat zij tijdig over relevante en betrouwbare informatie beschikt. Om de informatiestromen te beheersen heeft een organisatie een proces nodig dat bepaalt wie er waneer toegang heeft tot informatie.

2.1 Definitie Logische Toegangsbeveiliging

In de literatuur worden diverse definities gehanteerd voor Logische Toegangsbeveiliging (LTB). In bijna alle definities staat het beheersen van toegang tot gegevens centraal. Bij de uitwerking van onze scriptie hebben we de volgende definitie gebruikt voor Logische Toegangsbeveiliging:

“Logische Toegangsbeveiliging is het geheel van maatregelen om

de toegang tot gegevens te beheersen

Voor het beheersen van toegang tot gegevens worden maatregelen genomen. Deze maatregelen kunnen worden gecategoriseerd naar de aard van de maatregel. Hierbij worden door Van Praat (2005) beheersingsmaatregelen onderscheiden in:

- Organisatorische beheersingsmaatregelen - Procedurele beheersingsmaatregelen - Technische beheersingsmaatregelen

De organisatorische beheersingsmaatregelen richten zich op het structureren van een organisatie. Bij Logische Toegangsbeveiliging kan men hierbij denken aan hoe de verantwoordelijkheid voor de gebruikersrechten binnen een organisatie is belegd. De procedurele maatregelen zorgen ervoor dat werknemers in een organisatie op een gestructureerde en systematische manier met elkaar samenwerken. De procedures voor het toekennen en afnemen van rechten van gebruikers zijn procedurele beheersingsmaatregelen die een belangrijke rol spelen bij Logische Toegangsbeveiliging. De laatste technische beheersingsmaatregelen bevinden zich in de IT middelen. Hierbij gaat het om de daadwerkelijke gebruikersprofielen en de daarbij horende autorisatieobjecten.

2.2 Redenen voor verbetering

Bedrijfsprocessen veranderen continu en door de veranderingen worden ook de ondersteunende informatiesystemen aangepast. Als de Logische Toegangsbeveiliging niet goed onderhouden wordt, dan leidt dit er toe dat de Logische Toegangsbeveiliging na verloop van tijd niet meer voldoet aan de wensen van de organisatie en er een verbetering van de Logische Toegangsbeveiliging noodzakelijk is.

IT-Auditing vrije Universiteit Amsterdam 8/25

Bij het uitvoeren van ons onderzoek zijn we drie verschillende redenen tegen gekomen waarom een organisatie de Logische Toegangsbeveiliging wil verbeteren: Inzichtelijkheid, Effectiviteit en Efficiëntie.

Inzichtelijkheid Mede door een aantal grote boekhoudschandalen in de afgelopen jaren (denk aan Ahold, Enron, Parmalat en Worldcom) is het voldoen aan wet- en regelgeving een actueel onderwerp geworden. Wetgeving verplicht organisaties maatregelen te implementeren om aan te tonen dat de organisatie de belangrijkste risico’s binnen haar bedrijfsprocessen beheerst. Voorbeelden van dergelijke wet- en regelgeving zijn de ‘Sarbanes Oxley Act’ uit de Verenigde Staten en de ‘Code Tabaksblat’ uit Nederland. Logische Toegangsbeveiliging maakt vaak deel uit van de beheersmaatregelen waar een organisatie op steunt. Hierdoor moet een organisatie meer dan voorheen in staat zijn om aan te tonen dat de toegangsrechten in een systeem tijdig en juist zijn geïmplementeerd. Tijdens audits blijkt regelmatig dat organisaties niet in staat zijn om aan te tonen dat zij de autorisaties binnen hun applicaties adequaat beheersen. Zo wordt er vaak gebruik gemaakt van ongepersonaliseerde accounts of krijgen gebruikers meer rechten dan zij voor hun werkzaamheden nodig hebben.

Effectiviteit De tweede reden voor het veranderen van de Logische Toegangsbeveiliging heeft betrekking op de effectiviteit van het gebruikersbeheer in de gegevensverwerkende systemen. Een goed ingerichte Logische Toegangsbeveiliging stelt de ICT-afdeling in staat om medewerkers de juiste toegang te geven tot de benodigde gegevensverwerkende systemen of om de toegang van medewerkers te verwijderen. Het optimaliseren van het gebruikersbeheer leidt er toe dat autorisaties accuraat worden afgehandeld, waardoor oneigenlijk gebruik wordt tegen gegaan. Indien de processen rondom de Logische Toegangsbeveiliging goed georganiseerd zijn, dan is de ICT-afdeling van een organisatie beter in staat om de gebruikers in de organisatie te ondersteunen.

Efficiëntie De laatste reden voor het verbeteren van de Logische Toegangsbeveiliging kan gezocht worden in efficiëntie. Er kunnen kostenbesparingen plaatsvinden zowel in de primaire bedrijfsprocessen als in de ondersteunende diensten. Bij een goede Logische Toegangsbeveiliging kunnen medewerkers eerder aan de slag door een snellere afhandeling van wijzigingsverzoeken bij het gebruikersbeheer. De tweede besparing vindt plaats in de gebruikersbeheerprocessen. Doordat het proces efficiënt is ingericht zullen er minder handelingen nodig zijn van de medewerkers met als gevolg dat deze mensen op andere taken kunnen worden ingezet. De totale kosten van het gebruikersbeheer nemen hierdoor af.

IT-Auditing vrije Universiteit Amsterdam 9/25

2.3 Conceptueel model Logische Toegangsbeveiliging

Aan het begin van het onderzoek hebben wij de indruk gekregen dat bij het uitvoeren van Logische Toegangsbeveiliging projecten niet alle relevante gebieden in voldoende mate worden meegenomen. Om dit vermoeden inzichtelijk te maken hebben we een conceptueel model opgezet die de relatie weergeeft tussen Logische Toegangsbeveiliging en verschillende gebieden.

Het model geeft de positie weer van een Logische Toegangsbeveiliging project binnen een organisatie. Het model geeft echter geen invulling aan de wijze waarop het project moet worden uitgevoerd om de gewenste resultaten te realiseren.

In het conceptueel model staat een zestal gebieden, welke gezamenlijk invulling geven aan de Logische Toegangsbeveiliging binnen een organisatie (zie figuur 1). In de onderstaande toelichting staat een beschrijving van de gebieden en hun relatie met logische toegangsbeveiliging.

Figuur 1 Conceptueel model Logische Toegangsbeveiliging

Bedrijfsstructuur Onder Bedrijfsstructuur wordt de structuur van een organisatie verstaan die gehanteerd wordt om het Bedrijfsproces uit te voeren. Een goede illustratie van de Bedrijfsstructuur is een organogram. Een organogram kan afdelingen bevatten en functies binnen de afdelingen, maar ook de namen van de medewerkers die een bepaalde functie uitvoeren. Het is ook mogelijk om een Bedrijfsstructuur in andere dimensies weer te geven, voorbeelden hiervan zijn: Project structuren, Cost Center structuren en Geografische structuren.

Ontwerpers kunnen de Bedrijfsstructuur als gegeven gebruiken om de Logische Toegangsbeveiliging in te richten. Vaak hebben managers de wens om de toegangsrechten van een medewerker te beperken tot bepaalde Cost Centers of een medewerker heeft bepaalde toegangsrechten alleen nodig binnen zijn of haar eigen afdeling.

IT-Auditing vrije Universiteit Amsterdam 10/25

Bedrijfsproces Het Bedrijfsproces gebied bevat de processen die binnen een organisatie plaatsvinden. Dit zijn onder andere de primaire bedrijfsprocessen waar een organisatie haar bestaansrecht aan ontleent. Daarnaast maken de secundaire bedrijfsprocessen deel uit van het Bedrijfsproces gebied. Dit zijn de ondersteunende processen die een organisatie uitvoert om de primaire bedrijfsprocessen zo efficiënt en effectief mogelijk te laten draaien.

Logische Toegangsbeveiliging heeft een overlap met een Bedrijfsproces op het moment dat een deel van het proces ondersteund wordt met IT-middelen. Op dat moment ontstaat de vraag wie wat mag doen in een bepaald Bedrijfsproces en op welke wijze. Zo kan de Logische Toegangsbeveiliging bij een inkoopproces bepalen tot welk bedrag een inkoper mag inkopen. En voor het beheerproces van een database kan men bepalen welke parameters een beheerder mag wijzigen. Adequate Logische Toegangsbeveiliging noodzakelijk als maatregel om de vertrouwelijkheid en integriteit van de gegevens in het Bedrijfsproces te waarborgen.

IT-Middelen IT-Middelen bevatten de IT systemen die medewerkers ondersteunen bij het uitvoeren van hun werkzaamheden. De term IT systemen moet hierbij ruim geïnterpreteerd worden. Het kan bestaan uit hardware, applicaties, operating systemen, databases, enzovoorts. Het geheel van IT-Middelen verzorgt het geautomatiseerde deel van een Bedrijfsproces.

De daadwerkelijke Logische Toegangsbeveiliging wordt verzorgt door de IT-Middelen. Doordat de code in de IT-Middelen op een bepaalde manier in te stellen kan men de Logische Toegangsbeveiliging afdwingen. De Logische Toegangsbeveiliging is volledig afhankelijk van de mogelijkheden die de IT-Middelen geven. IT-Middelen leggen technische beperkingen op aan de inrichting van Logische Toegangsbeveiliging.

IT-Architectuur De IT-Architectuur gaat in op het idee achter de inrichting van de IT-Middelen. Bij de ontwikkeling van IT-Middelen kan de Architectuur gezien worden als een uitgangspunt voor het functioneel ontwerp. De fabrikanten van IT-Middelen passen hun producten vaak aan op basis van de ideeën die afkomstig zijn uit het Architectuur gebied. Een Architectuur hoeft niet altijd direct te implementeren te zijn in de IT-Middelen.

Een Architectuur is ook nodig bij het ontwerp van de Logische Toegangsbeveiliging. Hierbij gaat het Architectuur in op hoe de Bedrijfsstructuur en het Bedrijfsproces vertaald kunnen worden naar de IT-Middelen. Het eerder genoemde Role Based Access Control (RBAC) is een goed voorbeeld van een Architectuur met betrekking op Logische Toegangsbeveiliging.

Beheer Proces Het Beheer Proces bevat de dagelijkse beheerwerkzaamheden die een organisatie uitvoert om de middelen die het Bedrijfsproces ondersteunen goed werkend te houden. In tegenstelling tot een project gaat het hierbij niet om eenmalige gebeurtenissen, maar om regelmatig terugkerende activiteiten.

Ook bij Logische Toegangsbeveiliging dient een organisatie aandacht te schenken aan de procedurele inbedding in de organisatie. Na de implementatie van een beheersmaatregel komt de maatregel in productie en is onderhoud noodzakelijk. Organisaties zijn voortdurend in verandering en deze veranderingen moeten tijdig, juist en volledig worden doorgevoerd in de

IT-Auditing vrije Universiteit Amsterdam 11/25

beheersmaatregelen. Het is de taak van het Beheer Proces om de Logische Toegangsbeveiliging te onderhouden na implementatie.

Project Management Naast procesmatig onderhoud dat uitgevoerd wordt door Beheer Proces zijn er ook met regelmaat wijzigingen welke niet efficiënt opgelost kunnen worden door het Beheer Proces. In dat geval wordt een project opgestart. Het Project Management biedt methoden en technieken om dergelijke grote wijzigingen gestructureerd uit te voeren.

De verbetering van Logische Toegangsbeveiliging wordt door een organisatie vaak als project opgepakt. Het Project Management wordt hierbij gebruikt om eenmalig een grote verbeterslag te maken in de Logische Toegangsbeveiliging. Het Project Management is bij het uitvoeren van een project verantwoordelijk voor het behalen van de projectdoelstellingen. Hierbij moet het Project Management rekening houden met de bestaande situatie bij de andere gebieden uit het conceptueel model.

IT-Auditing vrije Universiteit Amsterdam 12/25

3 Role Based Access Control (RBAC)

In dit hoofdstuk wordt op hoofdlijnen het RBAC model toegelicht. Tevens is ingegaan op de algemene projectcyclus, welke ook van toepassing is bij de implementatie van RBAC.

3.1 Theorie

Een van de problemen waar veel organisaties mee te maken hebben is het niet efficiënt en effectief kunnen beheren van toegangsrechten in IT systemen. Om het beheerproces te verbeteren probeert men de beheertaak beter te structureren en te vereenvoudigen. Om dit te bereiken worden autorisaties veelal samengevoegd in een standaard set van autorisaties. Een dergelijke set van autorisaties kan vervolgens toegekend worden aan meerdere gebruikers die dezelfde rechten nodig hebben. Men hoeft dus niet meer alle autorisaties individueel toe te kennen, waardoor het beheer wordt vereenvoudigd.

In 1992 schrijven D.F. Ferraiolo and D.R. Kuhn een artikel over de toepassing van autorisatiesets binnen applicaties. Zij noemen de door hen gehanteerde aanpak “Role Based Access Control”. Ook zij herkennen de problemen die organisaties hebben bij het beheren van autorisaties in applicaties. Het RBAC model dat zij beschrijven gaat verder dan het alleen groeperen van autorisaties, maar kijkt ook naar de structuur van de organisatie. Op basis van de functies binnen een organisatie worden de autorisaties ingericht. Iedere functie binnen de organisatie krijgt een eigen rol met daarin zijn autorisaties.

De Bedrijfsstructuur van een organisatie wordt hierbij vertaald naar autorisaties in de IT-Middelen die het Bedrijfsproces ondersteunen. Door deze werkwijze gebeurt het creeëren van rollen en het toewijzen van rollen aan gebruikers op een meer gestructureerde manier. In het originele RBAC model gaat men er vanuit dat iedere functie een rol krijgt. Eventueel kunnen deze rollen nog gelaagd worden opgebouwd. Een voorbeeld hiervan is een Hoofd Inkoop die alle autorisaties heeft van een Assistent Inkoop, aangevuld met een aantal specifiek autorisaties.

3.2 Ontwikkelingen

Na de eerste RBAC implementaties is gebleken dat de originele RBAC oplossing waarbij iedere functie een eigen rol krijgt in veel gevallen leidt tot een wildgroei aan rollen. Dit wordt veroorzaakt doordat veel functies op het eerste oog identiek zijn, maar in de praktijk toch verschillen bevatten. Uiteindelijk hebben deze verschillen als gevolg dat alle functies uiteindelijk een eigen rol nodig hebben.

Figuur 2 Role Based Access Control model

IT-Auditing vrije Universiteit Amsterdam 13/25

In de nieuwere RBAC modellen wordt beter rekening gehouden met kleine verschillen die tussen functies binnen een organisatie bestaan. Door een onderscheid te maken tussen statische en dynamische eigenschappen van een rol kunnen flexibele rollen worden gecreeërd. De flexibiliteit zorgt ervoor dat de functies met kleine verschillen toch gebruik kunnen maken van dezelfde rol. Deze flexibiliteit wordt gecreëerd door gebruik te maken van variabele attributen bij een rol. Zo kan de afdeling van een HR medewerker als attribuut worden meegenomen. Door dit attribuut mee te nemen in de rol van de HR medewerker kunnen de bevoegdheden beperkt worden tot de eigen afdeling. Dit heeft als voordeel dat er niet voor elke afdeling een aparte HR rol aangemaakt moet worden, maar dat men één HR rol kan gebruiken voor meerdere afdelingen. Het gebruik van attributen en het maken van flexibele rollen heeft de naam RBAC 2.0 mee gekregen. De dynamische eigenschappen van RBAC 2.0 maken het ontwerpen en invoeren van de RBAC 2.0 oplossing nog complexer dan het originele RBAC, waardoor men meer risico loopt dat het project mislukt.

In de afgelopen tijd zijn artikelen verschenen die verder kijken dan de oplossing beschreven RBAC 2.0. Het grootste punt van kritiek op RBAC 2.0 is dat het net als de originele RBAC een eenmalig karakter heeft. De autorisaties worden eenmalig berekend voor een medewerker op basis van zijn functie. Vervolgens blijven de rechten hetzelfde totdat de functie van de medewerker wijzigt en er opnieuw een eenmalige berekening plaatsvindt van de autorisaties. De volgende stap in het RBAC groeimodel is dan ook de ontwikkeling van geautomatiseerde autorisaties die continu worden bijgewerkt. Hierdoor ontstaat er een rol die van tijd tot tijd verandert op basis van gegevens uit externe bronnen. De rechten van de eindgebruiker in een applicatie passen zich aan op basis van gegevens uit andere systemen. Zo kunnen de autorisaties van een gebruiker veranderen tijdens de berekening van de kwartaalcijfers van een bedrijf, terwijl zijn functie niet is verandert. Deze continue berekening van autorisatie objecten per functie wordt in de literatuur ook wel RBAC 3.0 genoemd.

3.3 Techniek

In de IT wereld zijn er diverse leveranciers die op RBAC gebaseerde producten aanbieden als oplossing voor het Logische Toegangsbeveiliging problematiek. In dit hoofdstuk gaan we dieper in op hoe deze producten zijn opgebouwd en welke verschillende systemen er onderscheiden kunnen worden. Het is de bedoeling om een gevoel te krijgen van de typen systemen die aanwezig (kunnen) zijn bij een implementatie van RBAC.

Voor het overzicht zijn de verschillende producten opgesplitst in een viertal typen (zie Figuur 3). Het eerste type Gebruikersbeheer administreert de Bedrijfsstructuur en medewerkers van een bedrijf. In het tweede type Rollenbeheer worden gebruikers gekoppeld met een functie in het Bedrijfsproces. Provisioning is het derde type, provisioning systemen zorgen voor de koppeling tussen de Rollenbeheer systemen en de daadwerkelijke applicaties en andere doelsystemen waarvoor de RBAC ingericht wordt. Op basis van de gegevens in het Rollenbeheer worden de settings en autorisatie objecten in de applicaties aangepast. De Applicaties zijn het laatste type binnen RBAC gerelateerde IT systemen.

IT-Auditing vrije Universiteit Amsterdam 14/25

Gebruikersbeheer Rollenbeheer Provisioning

Applicatie X

Applicatie Y

Figuur 3 Type systemen in een RBAC oplossing

Gebruikersbeheer houdt de stamgegevens bij van de medewerkers en is een bronsysteem voor de Logische Toegangsbeveiliging. Vaak is het Gebruikersbeheer afgeleid uit HR systemen van een bedrijf. Dergelijke systemen bevatten informatie als NAW- en salaris gegevens, maar ook de bedrijfsfunctie en afdeling informatie staat vaak verwerkt deze systemen. Voorbeelden van HR-systemen zijn Peoplesoft en de HR module van SAP. Veel van deze systemen zijn in eerste instantie ontworpen voor salarisverwerking en administratie doeleinden. Bij de ontwikkeling van RBAC is men gaan beseffen dat deze systemen belangrijke informatie kunnen leveren voor de autorisatie binnen applicaties.

Rollenbeheer levert een koppeling tussen IT gebruikers en hun functie in termen van IT applicaties. Een voorbeeld van een Rollenbeheer systeem is de security manager van BHold. BHold definieert “Organizational Units” waarin de rechten per rol gegroepeerd kunnen worden voor een of meerdere applicaties. Door de gebruiker te koppelen aan de juiste groepen kan vervolgens zijn autorisatieprofiel berekend worden.

Op het moment dat een autorisatie profiel berekend is, moet het uitgerold worden naar de daadwerkelijke applicaties. Provisioning biedt oplossingen om dit geautomatiseerd uit te voeren. Dergelijke systemen kunnen op basis van de gegevens uit het Rollenbeheer gebruikers aanmaken, rollen bewerken en toekennen aan gebruikers. Een voorbeeld van een provisioning leverancier is IBM.

Uiteindelijk komen de autorisaties in de bedrijfsapplicaties en andere doelsystemen terecht. Voorbeelden applicaties en doelsystemen zijn ERP systemen zoals SAP, maar ook boekhoud- en consolidatie applicaties zijn goede voorbeelden. Daarnaast kunnen ook operating systemen als Windows en Unix een doelsysteem zijn. In principe kunnen in deze categorie alle IT systemen voorkomen waarin autorisaties gekoppeld worden aan gebruikers.

3.4 Projectfasen

Een RBAC project bestaat uit verschillende fasen. Aan de hand van het Projectfasen model van Wijnen zijn de verschillende fasen beschreven. In dit model worden zes fasen onderkend in de levenscyclus van een project (zie Figuur 4). Het project begint hierbij met een idee in de initiatie fase en het eindigt bij de nazorg van het uitgevoerde project.

IT-Auditing vrije Universiteit Amsterdam 15/25

Figuur 4 Projectfasen volgens Wijnen

Initiatiefase In de initiatiefase wordt duidelijk gemaakt waarom een organisatie een project wil starten. De initiatiefase begint met een globaal idee om iets te verbeteren. Op basis van het idee wordt een concrete invulling gegeven aan de doelstellingen van het project. Er wordt bepaald wat aan het einde van het project opgeleverd moet zijn om het project als succesvol te beschouwen. In de initiatiefase wordt naast het projectresultaat ook de scope van het LTB-project benoemd. In de scope staat de afbakening van het project beschreven. Hieronder vallen de bedrijfsprocessen, afdelingen en systemen die worden meegenomen bij uitvoeren van het LTB-project.

Definitiefase De tweede fase in het project management model van Wijnen is de definitiefase. Tijdens de definitiefase worden op basis van de doelstellingen de eisen en wensen aan het projectresultaat uitgewerkt. Het globale project dat beschreven is in de initiatiefase wordt uitgewerkt naar een meer gedetailleerd projectplan. Het projectplan gaat in op de belangrijkste activiteiten van de opvolgende fasen en beschrijft de verschillende belanghebbers bij het project.

Ontwerpfase In de ontwerpfase zoeken de projectleden naar concrete oplossingen ten aanzien van de eisen en wensen die opgesteld zijn in de definitiefase. Men vergelijkt hierbij de verschillende oplossingen met de originele doelstellingen van het project. Tevens kijkt het projectteam in hoeverre iedere oplossing invulling geeft aan de eisen en wensen uit de definitiefase. Uiteindelijk wordt één model geselecteerd om worden uitgewerkt naar specifiek ontwerp. De uitwerking van dit ontwerp is het eindproduct van de ontwerpfase.

Voorbereidingsfase In de voorbereidingsfase wordt het uiteindelijke ontwerp vertaald naar een praktisch realiseerbaar eindproduct. Alle hulpmiddelen, materialen en voorschriften die nodig zijn om het ontwerp te implementeren moeten aan het eind van deze fase gereed zijn. De praktische problemen die zich voordoen bij het implementeren van een nieuw product moeten tijdens deze fase worden geïdentificeerd.

Realisatiefase De op één na laatste fase in het model van Wijnen is de Realisatiefase. In deze fase brengen de projectleden de gekozen oplossing in de praktijk. Het ontwerp wordt omgezet naar een productie omgeving en gaat deel uit maken van het Bedrijfsproces.

Nazorgfase Aan het einde van een project begint de Nazorgfase. Vanaf deze fase worden beheertaken uitgevoerd. Binnen het project moet men een opzet maken voor de benodigde

IT-Auditing vrije Universiteit Amsterdam 16/25

beheerwerkzaamheden en de beheerorganisatie. Bij een goed gestuurd project vindt er een gecontroleerde overdracht plaats van het project naar de beheerorganisatie.

IT-Auditing vrije Universiteit Amsterdam 17/25

4 Risico identificatie

Voor het identificeren van risico’s zijn interviews gehouden met RBAC experts. Tijdens de interviews is een volledige RBAC projectcyclus doorlopen. De belangrijkste risico’s uit de gesprekken zijn uitgewerkt in dit hoofdstuk.

De risico’s zijn beschreven in de volgorde waarin ze zich voordoen bij een RBAC project. Risico’s die zich voor het eerst voordoen bij de initiatiefase van een project staan in de eerste paragrafen, risico’s die pas tijdens de nazorgfase zich voordoen zijn in de latere paragrafen uitgewerkt.

4.1 Ambitieuze scope

Uit de interviews blijkt dat organisaties regelmatig RBAC projecten starten met een te ambitieuze scope. Tijdens de initiatiefase van een project moet het projectteam de scope van het project vastleggen. Men neemt teveel verschillende Bedrijfsprocessen, Bedrijfsstructuren en IT-Middelen in beschouwing. Hierbij onderschat het projectteam de complexiteit die dit met zich meebrengt.

Een RBAC project is veel meer dan het opstellen van een aantal rollen met rechten in de IT-Middelen. Zo moet men ook procedures ontwikkelen om de RBAC te onderhouden. Daarnaast moet men ondersteunende tooling inrichten voor provisioning van het RBAC ontwerp in de IT-Middelen. Een grotere scope maakt al deze activiteiten complexer. Het blijkt dat het Project Management niet altijd in staat is om de gevolgen van de scope op de voortgang van het project goed te kunnen overzien.

4.2 Onevenwichtig projectteam

Tijdens de interviews is het belang van een goede projectbezetting meerdere malen aan bod gekomen. Het is niet ongebruikelijk dat een organisatie een RBAC project als een puur technisch project start. De IT afdeling is vaak oververtegenwoordigd in het projectteam. Hierdoor komt binnen het project de nadruk te liggen op de IT-Architectuur en de IT-Middelen, terwijl er te weinig aandacht is voor de Bedrijfsprocessen en de Bedrijfsstructuur.

4.3 Complicaties door IT systemen

Als derde risico zijn tijdens de interviews de complicaties naar voren gebracht die door de bestaande IT-Middelen worden veroorzaakt. Hierbij is het risico dat het projectteam het gewenste ontwerp niet kan vertalen naar een technische oplossing. Tijdens een van de interviews is het voorbeeld gegeven van applicaties die geen onderscheid maken in ‘lees’ en ‘schrijf’ rechten. Als er dit soort beperkingen zijn dan is er een grote kans dat de keuzes op rolniveau niet te vertalen zijn naar de onderliggende autorisaties op applicatieniveau.

Een tweede voorbeeld van de mogelijke complicaties door de IT systemen is het feit dat men RBAC moet implementeren in een productie omgeving. De bestaande IT-Middelen kunnen vervuilde autorisatiegegevens bevatten, waardoor het projectteam een ontwerp niet volledig

IT-Auditing vrije Universiteit Amsterdam 18/25

kan invoeren. Bestaande rollen en accounts kunnen inconsistente naamgeving hebben en ook kan er sprake zijn verouderde accounts in productiesystemen. Doordat de primaire bedrijfsprocessen gebruik maken van de vervuilde accounts is het opruimen van de vervuiling niet eenvoudig. Deze activiteiten zijn vaak niet meegenomen in de initiële opzet van het project.

4.4 Veranderende omgeving

Het implementeren van een RBAC oplossing is vaak een langlopend traject. Tijdens het ontwerpen en uitrollen van een RBAC oplossing kunnen de gebieden waar de LTB op betrekking heeft veranderen. De startsituaties die gebruikt zijn in de ontwerpfase kunnen veranderd zijn op het moment van de realisatiefase. Bij een interview is het voorbeeld gegeven van een HR afdeling die tijdens de realisatiefase de functiebenamingen had aangepast. Door dergelijke organisatorische wijzigingen kunnen inconsistenties ontstaan tussen het RBAC ontwerp en de organisatie.

De tegenvallers uit het voorbeeld gebeuren buiten de invloed van het Logische Toegangsbeveiliging project om. De dergelijke wijzigingen zorgen voor extra werk, waardoor het moeilijker wordt om tot het geplande resultaat te komen binnen de geplande tijd.

4.5 Verkeerde uitrolstrategie

Voor het uitrollen van een RBAC oplossing worden in de praktijk vaak twee verschillende strategieën gehanteerd. In de eerste strategie rolt het projectteam de RBAC oplossing uit per bedrijfsonderdeel, waarbij voor een kleine groep gebruikers rollen worden gecreëerd waarmee alle autorisaties in onderliggende IT systemen worden aangestuurd. Bij de tweede strategie vindt de uitrol plaats per IT systeem. Hierbij maakt het projectteam voor alle gebruikers een RBAC ontwerp, waarbij de IT systemen één voor één worden toegevoegd.

Uit de interviews blijkt dat de keuze van de tweede uitrolstrategie een risico is voor het succesvol zijn van het project. Hierbij wordt de gehele organisatie in één keer geraakt bij de implementatie. Dit heeft tot gevolg dat de hele organisatie input moet leveren voor een goede koppeling tussen de Bedrijfsprocessen en het RBAC ontwerp. Het is moeilijk om dergelijke vertegenwoordiging vanuit de organisatie in één keer bij het project te betrekken. Een tweede reden voor het hoge risico dat deze uitrolstrategie met zich meebrengt is de zichtbaarheid van de resultaten. Een ontwerp voor de hele organisatie uitwerken neemt meer tijd in beslag. Daarnaast zijn de resultaten pas op het allerlaatste moment zichtbaar. Door de relatief slechte zichtbaarheid van de voortgang kan het draagvlak voor het project vanuit de organisatie afnemen.

4.6 Ontbreken testomgeving

Een projectteam ontwerpt Logische Toegangsbeveiliging bijna altijd voor een bestaande productieomgeving. Deze productieomgevingen zijn vaak te groot en te complex om een representatieve testomgeving in te richten. Het ontbreken van een representatieve testomgeving maakt het niet mogelijk om het ontwerp te valideren.

IT-Auditing vrije Universiteit Amsterdam 19/25

Onvoorziene fouten zijn bij een implementatie natuurlijk niet wenselijk, maar bij een RBAC project zijn de gevolgen erger dan normaal. Het implementeren van een RBAC ontwerp wijzigt namelijk de toegangsrechten van gebruikers, waardoor een eventuele fout directe gevolgen heeft voor de eindgebruikers. Hierbij kan gedacht worden aan het niet kunnen uitvoeren van werkzaamheden of het hebben van ongeautoriseerde toegang tot gegevens.

4.7 Ontbreken beheerproces

Uit de interviews blijkt dat de overdracht naar de beheerorganisatie een groot risico vormt bij een Logische Toegangsbeveiliging project. Het project is vaak alleen gericht op het maken en implementeren van een ontwerp. De benodigde beheerwerkzaamheden en de inrichting van een beheerorganisatie worden hierbij vaak achterwege gelaten.

Tijdens een van de interviews werd het voorbeeld gegeven dat er onduidelijke verantwoordelijkheden zijn bij het beheer van de gecreëerde rollen. Doordat rollen meerdere applicaties en bedrijfsprocessen kunnen raken is het vaak onduidelijk wie een beslissing mag maken voor het aanpassen van een rol. Als dit niet goed belegd wordt binnen een beheerorganisatie, dan komt het Logische Toegangsbeveiliging ontwerp niet meer overeen met de veranderende bedrijfsprocessen.

IT-Auditing vrije Universiteit Amsterdam 20/25

5 Risicoanalyse en aanbevelingen

In het vorige hoofdstuk zijn specifieke risico’s geïdentificeerd die zich voor kunnen doen bij een RBAC project. In dit hoofdstuk is het conceptueel model Logische Toegangsbeveiliging uit paragraaf 2.3 (Figuur 1) toegepast op de verschillende risico’s. Op basis van de analyse is per risico een aanbeveling gedaan om het specifieke risico tegen te gaan. In het volgende hoofdstuk is geëvalueerd in hoeverre de risico’s te verklaren zijn met behulp van het model en welke algemene risico’s uit het conceptueel model Logische toegangsbeveiliging zijn af te leiden.

5.1 Ambitieuze scope

Het risico van de te ambitieuze initiële scope is in het model het gebied waar de Logische Toegangsbeveiliging de overige gebieden raakt. Afhankelijk van de scope beslissingen worden bepaalde delen uit de verschillende gebieden in het model wel of niet meegenomen. Het risico van een te ambitieuze scope doet zich voor als men teveel elementen van een gebied in de scope plaatst. De scope kan te ambitieus zijn in verschillende gebieden uit het model. Zo kan een scope te ambitieus zijn doordat men teveel verschillende bedrijfsprocessen wil meenemen, maar ook doordat de hoeveelheid IT-Middelen die betrokken zijn bij de Logische Toegangsbeveiliging te groot is.

Om het risico te beheersen moet de scope overzichtelijk worden gehouden. Logische Toegangsbeveiliging projecten bevinden zich in een complexe omgeving en hier moet rekening mee gehouden worden. Het is verstandig om de Logische Toegangsbeveiliging op te delen in meerdere kleine projecten met een beperkte scope. Hierdoor is de complexiteit van de losse deelprojecten laag en wordt het Logische Toegangsbeveiliging project beter beheersbaar.

5.2 Onevenwichtig projectteam

In het model is een duidelijk onderscheid te zien tussen de techniek aan de rechterzijde en de bedrijfskant aan de linkerzijde van het model. Het risico van het onevenwichtige projectteam kan hierdoor duidelijk in het model worden weegegeven. In de praktijk is de techniek regelmatig oververtegenwoordigd bij een project en is de bedrijfskant ondervertegenwoordigd. Het zwaartepunt bij de meeste Logische Toegangsbeveiliging projecten ligt hierdoor teveel naar rechts.

Project Management en Beheer Proces zijn in staat om verschillen in het evenwicht te compenseren, maar slechts in beperkte mate. Bij te grote verschillen is het onmogelijk voor Project Management en Beheer Proces om de aansluiting tussen de techniek en de bedrijfskant te realiseren. Voor een succesvol Logische Toegangsbeveiliging project moeten de techniek en de bedrijfskant evenwichtig zijn vertegenwoordigd.

5.3 Beperkingen IT systemen

De technische beperkingen vanuit de IT bevinden zich in het conceptueel model aan de kant van de IT-Architectuur en IT-Middelen. De eisen en wensen uit het Bedrijfsproces en de

IT-Auditing vrije Universiteit Amsterdam 21/25

Bedrijfsstructuur kunnen in sommige gevallen niet ingevuld worden met de bestaande IT-Architectuur en IT-Middelen. In het model houdt de linkerkant dus niet altijd rekening met rechterkant. Hierdoor ontstaan verschillende verwachtingspatronen en loopt het project een groter risico om niet succesvol afgerond te worden.

Het projectteam moet conflicten tussen de techniek en de bedrijfskant de tijdig onderkennen. Verschillen tussen de technische mogelijkheden en de wensen vanuit het bedrijf moeten tijdens het project telkens op één lijn worden gebracht. Om het evenwicht tussen de rechter- en linkerzijde van het model te waarborgen moet men voorkomen dat een project voortgezet wordt terwijl de wensen niet in lijn zijn met de technische mogelijkheden.

5.4 Veranderende omgeving

De gebieden in het conceptueel model zijn veranderlijk in de tijd. Het is bijvoorbeeld mogelijk dat een reorganisatie de Bedrijfstructuur in een korte periode verandert. Ook de IT-Middelen in een Rekencentrum veranderen regelmatig. Bij Logische Toegangsbeveiliging wordt vaak maar eenmalig vastgelegd welke onderdelen van een gebied binnen de projectgrens vallen. Het mogelijk dat de gebieden veranderen waardoor de oorspronkelijke scope niet meer overeenkomt met de werkelijke of benodigde scope.

Op het moment dat er tegenvallers dreigen bij het project, moet de scope bijgesteld worden om vertraging te voorkomen. Een andere mogelijkheid is om door te gaan met de originele scope, waarbij de organisatie moet accepteren dat het project vertraging oploopt.

5.5 Verkeerde uitrolstrategie

Het risico van de verkeerde uitrolstrategie heeft te maken met de volgorde waarin delen van de Bedrijfstructuur en het Bedrijfsproces betrokken worden in het Logische Toegangsbeveiliging project. Bij een verkeerde uitrolstrategie is de rechterzijde van het conceptueel model centraal belegd, terwijl de linkerzijde van het model verspreid wordt over meerdere partijen. Hierdoor komt het initiatief bij het project meer bij de techniek kant te liggen.

Om een goede betrokkenheid te krijgen vanuit de bedrijfskant is het aan te bevelen om de betrokken afdelingen bij het project beperkt te houden. Bij de uitrolstrategie per bedrijfsonderdeel kan echter op relatief korte termijn een complete oplossing worden getoond. Ervaring opgedaan bij een bedrijfsonderdeel kunnen worden gebruikt voor het aanbrengen van verbeteringen voor een volgende uitrol. Ook is de koppeling met één bedrijfsonderdeel makkelijker te organiseren en te waarborgen tijdens het project.

5.6 Ontbreken testomgeving

Het risico van het ontbreken van de testomgeving laat zich moeilijk vatten in het conceptueel model. Het model is een moment opname van een Logische Toegangsbeveiliging project binnen een organisatie, terwijl het ontbreken van de testomgeving te maken heeft met de technische ondersteuning bij het project. De testomgeving maakt niet deel uit van de Logische Toegangsbeveiliging project, maar het is een ondersteunend middel dat de kans op fouten bij de ontwikkeling reduceert.

IT-Auditing vrije Universiteit Amsterdam 22/25

Het ontbreken van de testomgeving is bij veel Logische Toegangsbeveiliging projecten onvermijdelijk. Als maatregel kan een projectteam een beperkte scope hanteren om de complexiteit van het project te reduceren, waardoor de kans op fouten kleiner wordt. Dit maakt de noodzaak van een ontwikkelomgeving kleiner. Ook kunnen er maatregelen getroffen worden om de schade beperkt te houden op het moment dat de implementatie van een RBAC oplossing fout gaat. Hierbij kan men denken aan het opstellen van goede fall-back scenario’s en de inzet van extra beheerders, zodat de originele situatie hersteld kan worden wanneer er problemen zijn bij de implementatie. Een andere maatregel om de schade te beperken is het inrichten van een aparte incidentenprocedure voor het LTB-project.

5.7 Ontbreken beheerproces

Het ontbreken van het beheerproces wordt veroorzaakt doordat men bij het managen van het Logische Toegangsbeveiliging project niet tijdig onderkend dat ook het beheerproces veranderd moet worden. Bij het Project Management gebied wordt het Beheer Proces niet goed meegenomen, terwijl deze onlosmakelijk met elkaar zijn verbonden. Hierbij ligt de focus te veel op de bovenkant van het conceptueel model.

Om te voorkomen dat het beheer van de uiteindelijke Logische Toegangsbeveiliging een ondergeschoven kindje wordt, moet het projectteam zorgen dat de beheerorganisatie actief betrokken wordt bij het uitvoeren van het project. Tegelijk met de technische oplossingen moeten de beheerprocedures ontwikkeld worden. Hierbij moet men rekening houden dat de procedures in te bedden moeten zijn in de bestaande beheerorganisatie.

IT-Auditing vrije Universiteit Amsterdam 23/25

6 Evaluatie Model

In dit hoofdstuk is geëvalueerd hoe en waar het conceptueel model ondersteuning biedt bij het analyseren van de risico’s uit hoofdstuk 4. Hierbij is gekeken naar verschillende fouten die zich voor kunnen doen bij de positionering van het project in het conceptueel model. Vervolgens is aangegeven hoe deze fouten gerelateerd zijn aan de projectrisico’s die bij de interviews naar voren zijn gekomen.

Bij de projectpositionering in het conceptueel model zijn drie verschillende situaties te herkennen die een oorzaak kunnen zijn voor de geïdentificeerde risico’s.

In de eerste situatie ligt de nadruk vaak op de Informatie Technologie bij RBAC projecten. Logische Toegangsbeveiliging is onlosmakelijk verbonden met Informatie Technologie. Hierdoor heeft IT een belangrijke rol bij het uitwerken van een Logische Toegangsbeveiliging vraagstuk. Soms is de invloed van IT zo groot dat andere gebieden als het Bedrijfsproces en de Bedrijfsstructuur een ondergeschoven positie krijgen. In het model is dit het evenwicht tussen de rechter- en linkerzijde.

De tweede situatie komt voort uit de scope van een Logische Toegangsbeveiliging project. De geïdentificeerde risico’s bij RBAC projecten maken duidelijk dat een LTB-project snel groot en complex wordt. Dit maakt het lastig om de gevolgen van veranderingen binnen het project en de projectomgeving te overzien. In het model doet deze situatie zich voor als de scope van het Logische Toegangsbeveiliging project verkeerd gesteld wordt.

Een slechte relatie tussen de ontwikkel- en de beheerorganisatie is de laatste niet wenselijke situatie die zichtbaar wordt in het model. In de praktijk blijkt het lastig te zijn om een goede overdracht van het project naar de bestaande beheerorganisatie te realiseren. Het project is hierbij teveel gericht op het eenmalig goed inrichten van de Logische Toegangsbeveiliging, terwijl door veranderingen binnen een organisatie constant aanpassingen nodig zijn aan de inrichting. In het model is dit het evenwicht tussen de boven- en onderzijde.

Aan de hand van het conceptueel model zijn zes van de zeven risico’s te verklaren, slechts één risico is niet inzichtelijk te maken in het model. Tabel 1 geeft deze relaties weer.

Am

bitieuze scope

Onevenw

ichtig projectteam

Beperkingen

IT system

en

Veranderende

omgeving

Verkeerde

uitrolstrategie

Ontbreken

testomgeving

Ontbreken

beheerproces

1. Geen evenwicht Bedrijf / IT X X X

2. Veranderlijke Grens van LTB X X

3. Geen evenwicht Project / Beheer X

Tabel 1 Relatie risico's en project positionering

IT-Auditing vrije Universiteit Amsterdam 24/25

7 Conclusie

Doordat Logische Toegangsbeveiliging projecten complex zijn, is het van belang om de bijbehorende risico’s te onderkennen en te beheersen. In ons onderzoek hebben we risico’s bij Logische Toegangsbeveiliging projecten geïdentificeerd. Hiervoor is het implementeren van Role Based Access Control (RBAC) als voorbeeld genomen.

Het opgestelde conceptueel model blijkt nuttig te zijn voor het analyseren van de projectrisico’s die spelen bij Logische Toegangsbeveiliging projecten. Hierdoor hebben we aanbevelingen kunnen doen voor het beheersen van project risico’s bij het uitvoeren van LTB-projecten.

IT-Auditing vrije Universiteit Amsterdam 25/25

8 Literatuurlijst

8.1 RBAC Artikelen

- A. Koot (2007), “ABAC, meer ideetjes” Informatie beveiliging

- A. Hofman (2007), “Hoeveel rollen is genoeg?” Informatie beveiliging

- B. de Best (2006) “Identity management in kaart gebracht” – IT beheer

- A. Hofman (2005), “Rolgebaseerd autoriseren onder architectuur” - Informatie beveiliging

- Platform Informatiebeveiliging (2005), “Studie Role Based Access Control” Platform Informatiebeveiliging

- P. Mienes en B. Bokhorst (2003), “RBAC: gewoon doen”

- P. Mienes en B. Bokhorst (2003), “De (on)beheersbaarheid van toegangsbeveiliging”– Compact 2003

- D.F. Ferraiolo and D.R. Kuhn (1992) "Role Based Access Control" 15th National Computer Security Conference

8.2 Overige literatuur

- G. Wijnen (1996) “Projectmatig werken” Uitgeverij het Spectrum

- R.M.J. Christiaanse en J.C. van Praat (2005) “Inrichten en beheersen van organisaties” Uitgeverij ThiemeMeulenhoff