INHOUDSOPGAVE. Van de redactie 3. Column: Mag het een beetje meer wezen? 4 Gert van der Pijl. Reactie op de column van Anton Tomas 6 Ad de Visser

Colofon ‘De EDP-Auditor’ is een uitgave van de Nederlandse Orde van Register EDP-Auditors. Redactieraad drs. J.P. Harmens RE RA drs. M.A. Bongers RE RA drs. H.A. Kampert RE RA prof. ir. E.F. Michiels prof. dr. ir. J.A.E.E. van Nunen J.C. Vos RA H. de Zwart RE RA Redactie drs. Th.M.J.Gerritse RE drs. W.T. Houwert RE prof. dr. G.J. van der Pijl RE drs. E.J.M Ridderbeek RE CISA drs. R.J.Steger RE RA ir. A.J. Tomas RE RI RO drs. Th. Wijsman RE Eindredactie prof. dr. G.J. van der Pijl RE Bureauredactie M. Keyzer E-mail: [email protected] Uitgever Reed Business Information BV Postbus 152 1000 AD Amsterdam Tel.: 020-5159222 www.reedbusiness.nl

INHOUDSOPGAVE Van de redactie

3

Column: Mag het een beetje meer wezen?

4

Gert van der Pijl Reactie op de column van Anton Tomas

6

Ad de Visser Een audit op informatiearchitectuur: waar te beginnen?

9

Ruurd Smildiger De Wireless Toolbox van de IT-auditor

20

Mauriche Kroos en Robbert Kramer

Abonnementen ‘De EDP-Auditor’ wordt kosteloos aan de leden van de NOREA verzonden. De abonnementsprijs voor niet-leden bedraagt voor 2005 € 76,65 excl. btw. De verzendtoeslag voor België bedraagt € 6,95 en voor de Nederlandse Antillen en overige landen € 21,55. De prijs van losse nummers is € 21,53 excl. btw.

Ketenauditing in de publieke sector, complex en daarom spannend! 28

Per jaar verschijnen 4 nummers. Een abonnement kan worden beëindigd door schriftelijk vóór 1 november van een lopend jaar op te zeggen. Bij niet-tijdige opzegging wordt het abonnement met een jaar verlengd.

Bert Rechter

Abonnementenadministratie en lezersservice Reed Business Information BV Postbus 4, 7000 BA Doetinchem Tel.: 0314-358358 Fax: 0314-358161 E-mail: [email protected] Copyright Het geheel of gedeeltelijk overnemen van artikelen, schema’s of tekeningen uit deze uitgave is slechts toegestaan na voorafgaande schriftelijke toestemming van de uitgever.

Anastasia van der Meer en Leon Dirks Virtualisatie en de IT-auditor

IT-auditor: adviseur of controleur? Wilfried Olthof en Rainer Steger Een dag uit het leven van …

50

Arno Nuijten Automatiseringsbedrijf wint tuchtprocedure tegen RE RA

Bijdragen De redactie nodigt lezers uit een bijdrage te leveren aan ‘de EDP-Auditor’. U kunt uw bijdrage sturen naar de bureauredactie.

Kor Mollema

Vormgeving Studio Putto BNO, De Rijp

44

Interview met Paul van Kessel en reactie van Rob Fijneman

ISSN 0929-0583

Advertenties Elsevier Media Amsterdam Tel.: 020-5159666 Fax: 020-5159633 E-mail: [email protected] www.ema-online.nl Geldend advertentietarief 1-1-2005

39

Boekbespreking

52

55

Kracht van de vernieuwing; Visies op ICT Thomas Wijsman Van de NOREA Mededelingen

57

de EDP-Auditor nummer 3 2005

Van de redactie

Het is begin augustus en de eerste drukproef van dit nummer is binnen. Bij afwezigheid van de redactievoorzitter, zoals zo velen momenteel op vakantie, aan mij de eer om dit keer ‘Van de redactie’ te mogen verzorgen. Het weer in Nederland valt tegen, maar in mijn ogen niet de eerste drukproef. Bij het doorlopen hiervan constateer ik dat dit nummer zeer divers van samenstelling is. Voor elke ITauditor wat wils! Ik ben als redactielid dan ook zeer blij met de kwaliteit en de samenstelling. Zal ik alvast een tipje van de sluier oplichten inzake hetgeen u in dit nummer tegenkomt? Hier gaan we dan! Onze redactievoorzitter Gert van der Pijl heeft voor een prikkelende column gezorgd, waarin hij ingaat op mogelijk kruideniersgedrag binnen de beroepsgroep. ‘Mag het een beetje meer zijn of juist wat minder’ bij het bepalen van scope van een audit is een van zijn stellingen. Maken wij ons hieraan schuldig? Ook dit keer geeft de column voldoende stof om na te denken. Ad de Visser gaat vervolgens in op een eerdere column, geschreven door mijn collega-redactielid Anton Tomas. Hij reageert op Antons uitspraken inzake auditopleidingen en de ervaring die een IT-auditor minimaal zou moeten hebben. Hierbij brengt Ad een aantal nuances aan. Ik roep u hierbij op om vaker op deze wijze op columns te reageren! Ruurd Smildiger gaat in op het vraagstuk of en op welke wijze je informatiearchitectuur kunt auditen. De ermee gemoeide begrippen passeren de revue en ook geeft hij een aantal (inrichtings)normen inzake dit onderwerp. Het artikel biedt handvatten om een informatiearchitectuur te kunnen beoordelen. Mauriche Kroos en Robbert Kramer hebben reeds in de EDP-Auditor 4/2004 aandacht besteed aan WLAN-netwerken. In het eerste artikel hebben zij ons over het ‘wat’ verteld, nu gaan ze in op het ‘hoe’ testen ervan. Heeft u de schroevendraaier al paraat?! De auteurs Anastasia van der Meer en Leon Dirks gaan in op ketenauditing in de publieke sector. Zij geven aan dat het een complex vraagstuk is, als gevolg van het feit dat er

meerdere ministeries en ook audit teams bij betrokken zijn. Het artikel levert een aantal eye-openers op! Bert Rechter gaat in op het begrip virtualisatie. Dit houdt in dat software op een dusdanige wijze wordt gebruikt dat hardware of een gehele computeromgeving anders dan die waar de software feitelijk op draait, wordt geëmuleerd. Bert wijst de lezer op deze ontwikkeling en geeft aan dat dit aanvullende eisen aan de IT-auditor stelt bij het onderzoeken van een dusdanige omgeving. Rob Fijneman en Paul van Kessel hebben onder meer met elkaar gemeen dat zij beiden voorzitters zijn van een ITauditing-praktijk van een big four-kantoor en tevens hoogleraar zijn. Mede naar aanleiding van de recente oratie van Rob hebben Wilfried Olthof en ik over de toekomst van het beroep gesproken. Ik kan u verzekeren dat dit tot een aantal krachtige uitspraken van de beide heren heeft geleid! Dit keer heeft Arno Nuijten onze rubriek ‘Een dag uit het leven van’ verzorgd. Hij doet dit op een wel zeer bijzondere wijze! Kor Mollema gaat in op een recente tuchtrechtuitspraak. Aan de hand van een chronologische opbouw van feiten vertelt hij ons waar de casus betrekking op heeft en tot welke beslissingen de Raden en het College zijn gekomen. Ten slotte wordt dit nummer met een boekbespreking en mededelingen van het NOREA afgesloten. In de laatst genoemde rubriek roept mijn collega-redactielid Thea Gerritse u op om uw ervaringen inzake het gebruik van internet bij audits met ons te delen. Wij kijken al uit naar verfrissende invalshoeken! Ik wens u veel leesplezier toe. Rainer Steger

3

4


Column Mag het een beetje meer wezen? Gert van der Pijl

Een vraag gesteld door een collega: vertonen wij als ITauditors geen trekjes van kruideniers? Als wij verwikkeld zijn in wervingstrajecten, kunnen we het dan laten onze cliënten de vraag te stellen: mag het ietsje meer zijn? Met andere woorden, proberen wij onze cliënten altijd een stukje extra werk aan te smeren, misschien niet met het primaire doel die klant ook daadwerkelijk verder te helpen, maar vooral met het doel onze omzet te vergroten. We leven immers in een maatschappij waarin ieder van ons individueel wordt beoordeeld op zijn of haar prestaties. En het creëren van omzet is daarbij een niet onbelangrijk beoordelingscriterium. IT-auditing-organisaties zijn commerciële instellingen en daar is dergelijk gedrag gewenst. Het zou dus niet zo verwonderlijk zijn als er iets bestaat als een natuurlijke drive om onze omzet te vergroten. Wie zou het ons kwalijk nemen als we naar goed koopmansgebruik onze klant wijzen op de vele manieren die er veelal te bedenken zijn om de scope van de opdracht te verbreden en hem daardoor ‘een beetje meer’ met een grote meerwaarde te leveren. Waarom zouden we ons beperken tot een quick scan als er ook ruimte lijkt te zijn voor een niet alleen breed maar ook diepgaand onderzoek? Waarom alleen maar kijken naar de betrouwbaarheid van de financiële informatievoorziening als we met een klein beetje extra moeite ook een oordeel kunnen geven over de kwaliteit van de managementinformatievoorziening in zijn geheel? Waarom de risico-analyse niet

Prof. Dr. G.J. van der Pijl RE is hoogleraar IT-auditing aan de Erasmus Universiteit te Rotterdam, Program Director van de Eurac opleiding EDP-auditing en Director of Research van Eurac bv.

uitgebreid van de primaire processen tot een aantal belangrijke ondersteunende. En we hebben de wind mee: Sarbanes Oxley en Tabaksblat lijken de weg te banen tot een grote drift tot beheersing en zelfs bedrijven die niet onmiddellijk gedwongen zijn deze regelgeving na te leven omdat ze niet beursgenoteerd zijn, komen toch onder de druk om te zorgen dat hun organisaties ‘in control’ zijn. Een beetje extra audit kan daarbij nooit kwaad. Als wetenschapper moet ik voorzichtig zijn met het doen van uitspraken waarvoor ik niet uit eigen of andermans ervaring voldoende empirisch materiaal heb kunnen verzamelen. Helaas is het zo dat over de concrete uitvoering van het IT-auditing-beroep en de wijze waarop opdrachten worden geworven heel weinig is geschreven en nog minder met wetenschappelijke methoden is onderzocht. Ik moet dan ook veel terughoudendheid betrachten bij het doen van uitspraken over het realiteitsgehalte van bovenstaande beschouwing. Wat ik wel kan doen is wat doorredeneren op het bovenstaande en me afvragen of het nu eigenlijk goed of slecht zou zijn als de door mijn collega gestelde vraag met ja zou moeten worden beantwoord en IT-auditors dus inderdaad kruidenierstrekjes zouden bezitten. Vanwege mijn positie als hoogleraar met wat meer afstand tot de dagelijkse praktijk komt een dergelijke beschouwing uit onverdachte hoek. Ik heb immers geen commercieel belang bij de uitkomst daarvan. Laten we dus op dat spoor verdergaan. Een redenering naar analogie van ons voorbeeld is dan op zijn plaats. Het beeld van de kruidenier die altijd meer wil verkopen heeft voor de meeste mensen een negatieve bijklank. Het wordt, zo lijkt het, niet erg op prijs gesteld dat de kruidenier zijn klanten altijd iets meer wil leveren dan gevraagd, met de bedoeling daarmee meer omzet te creëren. Maar is dit


gedrag nu werkelijk zo negatief als het lijkt? Het antwoord op die vraag is naar mijn idee minder voor de hand liggend dan je zou denken. Het is afhankelijk van de aard van het verkochte product en van de kennis daarvan bij consument respectievelijk leverancier, in ons voorbeeld dus de kruidenier. Wanneer het gaat om een simpel product, waarvan de consument zelf voldoende kennis heeft, is er geen geldige reden voor het ‘beetje meer’ gedrag van de leverancier. De klant weet immers donders goed wat zijn eigen behoeften zijn en als het om een eenvoudig product gaat heeft hij er ook geen moeite mee om die behoefte om te zetten in een concrete vraag naar een concrete hoeveelheid product. Heel anders wordt het als het gaat om een complex product waarvan de leverancier veel kennis heeft maar de consument veel minder. In termen van de theorie over het afsluiten van contracten spreken we dan van een situatie met informatieasymmetrie. In dat geval is het voor de klant veel lastiger zijn wensen te vertalen in een concrete bestelling. Is het bijvoorbeeld beter om dat complete pakket met ingrediënten voor een oosterse maaltijd aan te schaffen of is het voordeliger de ingrediënten los aan te schaffen? En hoe staat het met de kwaliteit van de producten in beide varianten? Zijn ook andere combinaties mogelijk? Is er een voor- of nagerecht dat als ‘beetje extra’ zou kunnen worden meegenomen en dat voor weinig geld veel toegevoegde waarde levert? Nu kan de leverancier met zijn grote productkennis en waarschijnlijk ook kennis van de behoeften van verschillende typen gebruikers een belangrijke rol spelen. Hij kan de klant in de genoemde dilemma’s adviseren en hem zo helpen tot een veel verstandiger keuze te komen dan deze geheel op eigen kracht had gekund. Wel is het zo, dat daarbij niet alleen ‘beetje meer’- maar ook ‘beetje minder’-varianten als advies denkbaar zijn.

‘Kruideniersgedrag’ zou in dat geval kunnen betekenen: kennis van zaken betreffende de geleverde producten en inzicht in de behoeften van de klant. Wel zou de contractingtheorie vragen dat er mechanismen zijn die garanderen dat de klant een advies krijgt waarmee zijn doelen gediend zijn en dat niet primair bedoeld is om de zakken van de leverancier te spekken. De parallel met IT-auditors is nu makkelijk te trekken: daar waar sprake is van eenvoudige auditproducten heeft de klant weinig behoefte aan een ‘beetje meer houding’ van de IT-auditor. Integendeel: een dergelijke houding zou het vertrouwen van auditklanten in hun leverancier op de lange termijn ernstig kunnen schaden. Maar daar waar, zoals vaak het geval, sprake is van complexe auditproducten is het goed als de IT-auditor ‘kruideniersgedrag’ in positieve zin laat zien en de klant met kennis van zaken adviseert, bijvoorbeeld over diepgang en reikwijdte van de uit te voeren audit. In sommige gevallen kan dit leiden tot een ‘beetje meer’-advies, bijvoorbeeld in die gevallen waar een te smalle scoping van de audit ertoe leidt dat de problematiek van de klant niet werkelijk wordt opgelost. In andere gevallen zou het advies moeten luiden ‘een beetje minder’, bijvoorbeeld in gevallen waar een quick scan al veel inzicht kan verschaffen terwijl de klant vraagt om een breed en diepgaand onderzoek. In beide gevallen redeneert de auditor primair vanuit het belang van de klant. Terugkomend op de vraag die aanleiding gaf tot deze column concludeer ik dan ook dat wij auditors best wat meer de kruidenier mogen zijn, maar dan wel in de goede zin van het woord: soms ‘een beetje meer’, maar alleen als dat nodig is, en in andere gevallen ‘een beetje minder’ om de klant niet onnodig op kosten te jagen.

5

6


Reactie op de column van Anton Tomas Ad de Visser

‘Maar doodslaan deed hij niet, want tussen droom en daad, staan wetten in de weg en praktische bezwaren’, W. Elsschot Anton Tomas heeft al vaker een prikkelende bijdrage geschreven in ‘de EDP-Auditor’. Deze las ik dan met veel interesse, dacht er nog even over na en ging vervolgens weer over tot de orde van de dag. Dit zal waarschijnlijk bij meerdere lezers het geval zijn geweest, want er volgde zelden een publieke reactie op zijn uitdagende stellingen. De boodschap van Tomas in zijn meest recente column ‘Over de auditorsfuik en het nut van auditopleidingen’ intrigeerde mij echter zodanig dat een reactie ditmaal niet kon uitblijven. Is het inderdaad zo dat het uitvoeren van diepgaande IT-audits is voorbehouden aan mensen die een gedegen IT-kennis bezitten en ruime werkervaring in IT hebben opgedaan? Het interessante aan het betoog van Tomas is dat het op een aannemelijke wijze enkele bekende feiten samenvoegt en hier een verrassende conclusie aan verbindt. Hij ondersteunt zijn argumentatie met voorbeelden, zoals een allegorie uit de bouwsector en een beschrijving van een praktijksituatie waarin niet-auditors een audit uitvoeren op het gebied van informatiebeveiliging. Indien Tomas gelijk heeft, lijkt er dus in de toekomst geen plaats meer te zijn voor al die mensen ‘met relatief weinig werkervaring en ook nog met een vooropleiding in het verkeerde vakgebied’, die ‘onze postdoctorale opleidingen bevolken’. Tot op zekere hoogte heeft Tomas natuurlijk ook gewoon gelijk. Het is niet mogelijk IT-audits uit te voeren zonder een zekere affiniteit te hebben met het desbetreffende domein. Kennis van IT is onontbeerlijk en werkervaring in IT een pré. Dat deze condities geen voldoende voorwaarde zijn om IT-audits uit te kunnen voeren, wordt door

A.A.C. de Visser is werkzaam bij Fortis Audit Services/ICT Audit, en is tevens als docent verbonden aan de Postdoctorale opleiding EDP-Auditing aan de Erasmus Universiteit Rotterdam.

Tomas impliciet onderkend. Hij stelt immers dat: ‘zelfs IT-deskundigen een aanvullende IT-audit-opleiding nodig hebben’. Hij is echter te stellig als hij vervolgens beweert dat beide condities noodzakelijk zijn voor het kunnen uitvoeren van (diepgaande) IT-audits. Dit laatste is wat mij betreft onderwerp van discussie en zeker geen uitgemaakte zaak! Hoewel hij dit niet expliciet in zijn column vermeldt, refereert Tomas in zijn betoog, mijns inziens, aan twee bekende vraagstukken in IT-auditing, te weten: 1) is een goede IT-auditor een generalist of een specialist, en 2) is ITauditing ambacht of wetenschap? Deze vraagstukken zorgen voor een regelmatig terugkerende discussie tussen vakgenoten, maar kennen tot op heden geen algemeen geaccepteerde oplossing. Dit is tevens de kracht van het betoog van Tomas. Hij kiest ongemerkt positie in het aloude debat tussen generalist/specialist en academici/vaklieden en voegt daardoor stilzwijgend het volledige gewicht van deze positie toe aan zijn argumenten. In deze reactie zal ik enkele argumenten geven om de stellingen van Tomas te nuanceren. Ik doe dit aan de hand van een alternatief perspectief op de in zijn column geïntroduceerde audittypologie. De eerste twee soorten rechtvaardigen volgens Tomas geen universitaire auditopleiding: ‘Ze gaan niet diep en in de kern komt het neer op het afvinken van een rijtje regels’. ‘Het is zelfs heel goed denkbaar dat een groot deel van dit soort audits in de toekomst verregaand geautomatiseerd zal plaatsvinden’. Het derde type IT-audit heeft als kenmerk dat ‘de auditor diepgaand de werking van een bepaald technisch of organisatorisch systeem doorgrondt en analyseert en zich een mening vormt over de betrouwbaarheid van de functionaliteit ervan’. Het uitvoeren van dit laatste type IT-audit vereist – volgens Tomas – dat de IT-auditor over een gedegen IT-opleiding en relevante werkervaring beschikt. Uit de wijze waarop hij de twee ‘afvink-audits’ beschrijft, leid ik af dat Tomas deze inferieur acht aan de diepgaande IT-audit. Hij geeft daarmee een waardeoordeel zonder te verklaren waarop dit oordeel is gebaseerd. Waarde is ech-


ter een subjectief begrip en wordt in de regel bepaald door de gebruikers van de auditresultaten. In essentie bestaat het eindproduct van een audit uit een kwaliteitsoordeel. De audit kan betrekking hebben op het IT-object zelf (beoordelen van de intrinsieke kwaliteit) of het IT-object in relatie met zijn omgeving (beoordelen van de extrinsieke kwaliteit). De eerste vorm van kwaliteit komt bijvoorbeeld tot uitdrukking in de toegepaste constructie, de gebruikte componenten, de gehanteerde ontwikkelstandaarden, enzovoort, van het IT-object. Audits gericht op het vaststellen van de intrinsieke kwaliteit zijn vooral interessant voor bedrijven in de IT-sector zoals ontwikkelaars en leveranciers van IT-componenten. Het certificeren van producten heeft dan commerciële waarde. Voor het onderzoeken van de intrinsieke kwaliteit van IT-objecten is een gedegen IT-kennis noodzakelijk, bijvoorbeeld op IT-deelgebieden als software engineering, IT-architectuur, cryptografie en IT-security. Ik ben het in dit geval volledig met Tomas eens dat de kennis en kunde van een gemiddelde IT-auditor onvoldoende zijn om een dit soort ‘diepgaande IT-audit’ uit te voeren. Dergelijke onderzoeken wordt in de praktijk dan ook veelal uitgevoerd door een team van IT-deskundigen werkzaam bij officiële testen certificeringlaboratoria zoals TNO en NSA. De tweede vorm van kwaliteit komt tot uitdrukking in de bijdrage van een IT-object in een specifieke context. Denk bijvoorbeeld aan het gebruik of de inzet van het IT-object in een logistiek proces. Auditresultaten met betrekking tot de extrinsieke kwaliteit zijn vooral interessant voor het (lijn)management dat bijvoorbeeld wil weten in welke mate IT-objecten het realiseren van bepaalde bedrijfsdoelstellingen ondersteunen. Het lijkt erop dat de zogenaamde ‘afvink-audits’ uit de audittypologie van Tomas voornamelijk in audits met betrekking tot de extrinsieke kwaliteit van IT-objecten terug te vinden zijn. Hoewel een checklist in de IT-audit-praktijk een vaak voorkomend hulpmiddel is, impliceert dit niet onmiddellijk dat ‘een groot deel van dit soort audits in de toekomst verregaand geautomatiseerd zullen plaatsvinden’. Automatiseren is alleen mogelijk in situaties waarbij er een eenduidige interpretatie bestaat omtrent bijvoorbeeld norm, meetwaarden en beslissingsmodel. In de praktijk zal dit alleen voor een beperkt aantal IT-audits van toepassing zijn. Audits naar de extrinsieke kwaliteit van ITobjecten hebben veelal betrekking op complexe beheer- en sturingsvraagstukken waarbij het van belang is een multidisciplinaire benadering te hanteren.

De IT-auditor zal bij het beoordelen van de extrinsieke kwaliteit van een IT-object rekening moeten houden met de specifieke context waarin dit object zich bevindt. Hiertoe gebruikt de IT-auditor kennis uit de relevante disciplines, zoals bedrijfskunde, informatica, bedrijfseconomie en auditing. Het is juist deze mix van kennis – ‘op het snijpunt van organisatie en techniek’ – die nodig is bij de beoordeling van het gebruik van IT-objecten in bedrijfsprocessen. Een te eenzijdige focus op een van deze kennisdomeinen zou mogelijk tot een suboptimaal oordeel kunnen leiden. Uit het bovenstaande valt op te maken dat het merendeel van de IT-audits heden ten dage betrekking heeft op het beoordelen van de extrinsieke kwaliteit van IT-objecten en dat er ook bij dit perspectief sprake is van ‘diepgaande IT-audits’. Wat resteert is de vraag of het noodzakelijk is over gedegen IT-kennis te beschikken en/of ruime werkervaring in IT te hebben om dit soort IT-audits uit te voeren, zoals Tomas beweert? Ik ben van mening dat ook de ‘theoretische RE’ over voldoende kennis en kunde beschikt om een ‘diepgaande IT-audit’ uit te kunnen voeren naar de extrinsieke kwaliteit van IT-objecten. Voordat ik deze bewering nader toelicht, zal ik eerst een voorbeeld geven afkomstig uit de klinische psychologie. Gedurende haar opleiding krijgt een psychologiestudente een grote hoeveelheid theorie aangeboden. De vele modellen en concepten ontwikkelen de sensibiliteit van de studente, waardoor zij in staat is om diverse ziektebeelden te kunnen onderscheiden en herkennen. Tevens wordt aandacht gegeven aan veel voorkomende behandelmethoden (de zogenaamde best practices) en handelingskennis. Daarna volgt een praktijkstage. Daarin leert de studente bijvoorbeeld diagnoses te stellen en scherpt ze haar oordeelsvorming met betrekking tot de ernst van aandoeningen of complicaties. Gedurende de opleiding is er dus aandacht voor zowel theoretische kennis alsmede het opdoen van praktische ervaring. Beide condities zijn noodzakelijk om uiteindelijk zelfstandig als klinisch psycholoog aan de slag te kunnen. Je hoeft dus niet psychotisch te zijn (geweest) om een psychose te kunnen diagnosticeren of behandelen! De postdoctorale opleidingen EDP-Auditing kennen een soortgelijke structuur als in het bovenstaande voorbeeld, maar dan in een wat meer gecomprimeerde vorm. De student krijgt, meestal in het eerste jaar, relevante theorieën aangeboden afkomstig uit de onderliggende disciplines van IT-auditing. Door middel van deze theorieën ontwikkelt de sensibiliteit van de student ten aanzien van de specifieke problemen in het aandachtsgebied. De focus ligt

7

8


daarbij niet eenzijdig op informatica, maar benadrukt vooral het multidisciplinaire aspect. Daarnaast krijgen de studenten, veelal in het tweede jaar, een grote hoeveelheid opgaven die zijn gebaseerd op praktijkcases. Het intensief uitwerken en bespreken van deze praktijkcases – in groepsverband of individueel – scherpt het diagnostische en analytische vermogen alsmede de oordeelsvorming van de student. Het is juist deze combinatie van het aanbieden van multidisciplinaire theoretische kennis en het simuleren van praktijksituaties dat maakt dat de opleiding EDP-Auditing niet alleen compenseert voor een eventueel gebrek aan werkervaring in IT, maar bovendien een goede basis levert om audits naar de extrinsieke kwaliteit van IT-objecten te kunnen uitvoeren. De verplichting om daarnaast ten minste drie jaren relevante werkervaring te hebben, maakt dat ook de ‘theoretische RE’ in staat is om ‘diepgaande ITaudits’ uit te voeren. Je hoeft dus niet te kunnen programmeren om de ‘betrouwbaarheid van de functionaliteit’ van een informatiesysteem te kunnen beoordelen! Hetgeen Tomas voorstelt zal waarschijnlijk een utopie blijken. Er bestaan immers diverse praktische implicaties die de brede doorvoering van zijn voorstel zullen belemmeren. De term ‘IT-deskundige’ duidt bijvoorbeeld al op een zekere specialisatie. Iemand is deskundig op een specifiek terrein, maar niet noodzakelijkerwijs daarbuiten. Een IT-deskundige ten aanzien van IT-architectuur beschikt waarschijnlijk niet over de kennis om de kwaliteit van een Java-applicatie te kunnen beoordelen. In de praktijk zou de variatie aan IT-audit-specialismen enorm toenemen terwijl tegelijkertijd de inzetbaarheid van de desbetreffende IT-auditors flink zal afnemen. Dergelijke vergaand gespecialiseerde IT-auditors zul je overigens alleen maar bij de Big 4 aantreffen. Interne auditafdelingen zullen in de meeste gevallen een dergelijke specialisatie niet rendabel kunnen maken en moeten overgaan tot het ‘insourcen’ van deze kennis. Bedrijven die besluiten om hun IT-deskundigen als parttime IT-audi-

tor in te zetten om het werk van collega’s te beoordelen, krijgen daarmee geen audits (onafhankelijk!) maar peer reviews.

Ten slotte is de ‘auditorsfuik’ die door Tomas wordt beschreven natuurlijk ook van toepassing op deze IT-deskundigen: ‘zonder dagelijkse IT-werkervaring zal het ze moeilijk vallen hun IT-vakkennis op peil te houden, waardoor het ze onmogelijk wordt na enige tijd alsnog naar een IT-functie te kunnen ontsnappen’. Gelukkig heeft de IT-auditor met de ‘verkeerde vooropleiding’ in dit geval nog andere carrièremogelijkheden… Het is de functie van een columnist om een extreme positie in te nemen om daardoor andere mensen aan het denken te zetten. Ik denk dat Tomas daarin uitstekend is geslaagd. Het interessante van zijn column is natuurlijk niet zijn voorstel om het RE-register te sluiten voor personen onder de 35 jaar, maar de beweegreden(en) tot het schrijven ervan. Het zou kunnen dat Tomas niet tevreden is over de prestaties van IT-auditors in het algemeen en hij de oorzaken hiervoor zoekt in de (voor)opleiding van ITauditors. Zijn gegeneraliseerde oplossing heb ik in het bovenstaande, naar mijn mening, voldoende genuanceerd. Het is echter belangrijk te onderkennen dat wij beiden een positie innemen zonder dit te onderbouwen met gedegen en concrete onderzoeksresultaten. De wederkerende vraag of IT-auditing nu een vak of wetenschap is, is niet echt interessant. Het is veel interessanter te vragen of het mogelijk is om wetenschappelijk onderzoek uit te voeren naar of binnen IT-auditing. Aangezien er wereldwijd bij diverse universiteiten reeds auditingonderzoekprogramma’s lopen, is het antwoord op deze vraag al gegeven. Ik ben ervan overtuigd dat toegepast wetenschappelijk onderzoek op het gebied van ITauditing noodzakelijk is om de kwaliteit van IT-audits structureel te verbeteren. Zonder dergelijk onderzoek zullen we bijvoorbeeld nooit weten of er een causaal verband bestaat tussen (voor)opleiding van IT-auditors en de kwaliteit van IT-audit-resultaten.


Een audit op informatiearchitectuur: waar te beginnen? Stel dat je als IT-auditor gevraagd wordt om een oordeel te geven over de kwaliteit van een informatiearchitectuur. Wat dan? Wat is een informatiearchitectuur? Waar moet je op letten? Wat kun je doen?

Ruurd Smildiger

Dat die vraag een keer komt is niet ondenkbeeldig. Bedrijven en overheidsinstellingen moeten snel kunnen reageren op marktontwikkelingen en wijzigende weten regelgeving. De aanpasbaarheid van de achterliggende systemen blijkt dan vaak beperkt te zijn en gaat met grote inspanningen, dus kosten, gepaard. Terwijl het management juist de noodzaak ervaart dat systemen snel en tegen relatief lage kosten aangepast zouden moeten kunnen worden. Dit stelt eisen aan het systeemontwerp. Vergelijk het maar met het ontwerpen van een huis. Als je de wens hebt om in de toekomst van het dak een dakterras te maken, zul je bij het ontwerp van de dakconstructie en het bepalen van de locatie van een raam (dat later een deur kan worden) al rekening moeten houden met het dakterras. Dat is flexibiliteit inbouwen. Een ander voorbeeld is dat een architect zoekt naar eenvoudige oplossingen indien hij een huis ontwerpt dat meerdere malen gebouwd moet gaan worden en relatief snel en gemakkelijk te bouwen moet zijn. Hij zoekt naar reductie van complexiteit in zijn oplossingen. In de praktijk zijn voor dit soort wensen bij systeemontwerp grofweg twee mogelijke strategieën: 1. Systemen kunnen zodanig worden ontworpen dat ze niet of weinig aangepast hoeven te worden. Dit betekent de realisatie van generieke systemen met een groot aantal parameters. Met deze parameters kan het

R. Smildiger is werkzaam bij de Auditdienst van het ministerie van Onderwijs, Cultuur en Wetenschap in de functie van auditor. Sinds 1995 is hij werkzaam als IT-auditor.

systeem worden ingesteld op een groot aantal specifieke situaties. Veranderen de omstandigheden, dan worden de parameters in overeenstemming daarmee aangepast. Denk hierbij aan de ERP-systemen. 2. Systemen kunnen zodanig worden ontworpen dat aanpassingen snel en tegen relatief lage kosten worden aangebracht. Deze wens van systeemontwerp heeft geleid tot de architectuurgedachte en de ontwikkeling van informatiearchitecturen. Over deze laatste strategie gaat dit artikel. Onder de kop ‘Maar wat is nu architectuur?’ zal ik een schets geven van wat informatiearchitectuur kenmerkt. In de paragraaf ‘Alignment’ leg ik uit wat wellicht de belangrijkste schakel is om een architectuurproject te doen slagen: communicatie met het management. Daarbij wordt de koppeling gelegd met de mogelijke doeleinden van een informatiearchitectuur, namelijk een offensieve of defensieve toepassing. Daarna wordt beschreven hoe een project van informatiearchitectuur past in een systeemontwikkelingsproject. In de paragraaf daarna volgen de aandachtspunten die – naast de communicatie – van belang zijn voor het doen slagen van de implementatie van de informatiearchitectuur. Dit betreffen procesmatige aspecten. Om een informatiearchitectuur te kunnen beoordelen volgen drie modellen die een hulpmiddel daarbij kunnen zijn. Tot slot is een door mijzelf ontwikkeld normenstelsel opgenomen om de kwaliteit van een informatiearchitectuur te kunnen onderzoeken en die ook specifieke normen bevat voor een project waarin informatiearchitectuur wordt ontwikkeld. Voor het toetsen aan die normen kan één of meer van de modellen worden gebruikt.

9

10


Maar wat is nu architectuur? Als over een architectuur wordt gesproken, wordt vaak meteen gedacht aan een ontwerp van gebouwen. Dit sluit ook aan op de definitie van architectuur die in de ‘Dikke van Dale’ te vinden is, namelijk: Bouwkunst, de kunst en de leer van het ontwerpen en uitvoeren van bouwwerken. Is een informatiearchitectuur ook een kunst en leer van het ontwerpen en uitvoeren van een informatiebouwwerk? Het Genootschap van Informatie Architecten (GIA) hanteert de volgende definitie van informatiearchitectuur: Een Informatie Architectuur is de architectuur van de informatiehuishouding van een organisatie. In deze definitie – tot stand gekomen na een brede discussie met vakgenoten – valt op dat er gesproken wordt over informatiehuishouding in plaats van de vaker gebruikte term informatievoorziening. Dit suggereert dat informatie een resultante is van een breder geheel binnen een organisatie dan de afdelingen die direct betrokken zijn bij de informatieverschaffing. Er is inderdaad sprake van een informatiebouwwerk en de hier gestelde vraag kan dus met ‘ja’ worden beantwoord. Kenmerken van architectuur Een informatiearchitectuur heeft een vijftal definiërende kenmerken. Deze kenmerken zijn een vertaling van de kenmerken die [SAND97] heeft gegeven aan architectuur. Een eerste kenmerk van architectuur is dat deze de structuur van het object beschrijft. Als er sprake is van een informatiearchitectuur wil dit zeggen dat dit het ontwerp van de informatiehuishouding van een organisatie (conform de definitie van het GIA) beschrijft. Dat wil zeggen, beschrijft • uit welke componenten de informatiehuishouding van het betrokken bedrijf(sonderdeel) is samengesteld; • wat hun functie is, welke bijdrage ze elk leveren aan de bedrijfsuitoefening; • welke bijdrage ze elk leveren aan de realisatie van de doelstellingen uit het beleid; • hoe de componenten samenhangen. Als tweede kenmerk is genoemd dat architectuur het instrument is om de kwaliteit van het geheel te sturen. Kijkend naar informatiearchitectuur wil dit zeggen dat de informatiearchitectuur een instrument is voor het sturen van de kwaliteit van de informatiehuishouding als geheel. Hiermee wordt bedoeld de mate waarin de informatiehuishouding de bedrijfsuitoefening ondersteunt en flexi-

bel is. Voor de informatiearchitectuur betekent sturen van de kwaliteit in de eerste plaats dat er een duidelijke en zo eenduidig mogelijke relatie is tussen de doelstellingen van het bedrijf en de informatiecomponenten die aan de realisatie ervan een bijdrage leveren. Ten slotte betekent sturen van de kwaliteit van het geheel: suboptimalisatie tegengaan. Naast een duidelijke afbakening van de informatiecomponenten is daarom een goede onderlinge aansluiting van belang. Met andere woorden: binnen de informatiehuishouding zijn geen overlappen ten behoeve van de informatievoorziening en er zijn geen witte vlekken. Het derde kenmerk van architectuur is dat ze uitdrukking dient te geven aan een visie. Daarbij gaat het bij de informatiearchitectuur om de visie die het bedrijfsmanagement heeft op zijn bedrijfsuitoefening en de verbetering van de bedrijfsresultaten. Deze visie dient het uitgangspunt te zijn bij het ontwerpen van de informatiearchitectuur. De concretisering ervan is meestal verwoord in het informatiebeleid. Het informatiebeleid beschrijft op hoofdlijnen de gewenste bijdrage van de informatiehuishouding aan het realiseren van het bedrijfsbeleid. Naast een goede aansluiting op het bedrijfsbeleid betekent dit ook de mogelijkheid snel in nieuwe informatiebehoeften te voorzien, zonder daarbij steeds grote delen van de informatiehuishouding te moeten vervangen. Als vierde kenmerk van architectuur is genoemd dat ze resultaat is van onderhandeling. Een informatiearchitect krijgt te maken met veel partijen, eisen en belangen. Deze eis heeft meer betrekking op de wijze waarop de architectuur tot stand komt, dan op de inhoud ervan. Het ontwerpproces moet je zodanig organiseren, dat alle belanghebbende partijen tijdig betrokken worden. Als partijen te laat betrokken worden, hebben ze geen mogelijkheid meer zelf een bijdrage te leveren aan de oplossing. Het risico is dat het commitment voor het resultaat gering zal zijn. Daarnaast is het ook noodzakelijk dat de verschillende eisen met elkaar in overeenstemming zijn gebracht en zichtbaar en helder geformuleerd in het ontwerp zijn verwerkt. Een architectuur beschrijft niet alleen de structuur en de opbouw van het object zelf, maar ook de ontwikkeling en de bouw ervan. Het vijfde kenmerk is dat de informatiearchitectuur een scharnier is tussen ‘wensen’ en ‘doen’. Voor de informatiearchitectuur betekent dit kenmerk dat het een scharnierfunctie dient te vervullen tussen het bedrijfs- en het informatiebeleid enerzijds en de systeemontwikkeling anderzijds. Dit betekent dat je zowel de strategische wenselijkheid van de informatiearchitectuur als de technische en projectmatige uitvoerbaarheid ervan moet vaststellen.


De onderdelen van informatiearchitectuur en hun doel De informatiearchitectuur kan worden opgedeeld in een aantal specifieke onderdelen [VREV94] die allemaal hun eigen functie hebben. De informatiearchitectuur bestaat uit een applicatiearchitectuur, een gegevensarchitectuur en een technische infrastructuur. Applicatiearchitectuur (ook wel informatiesystemen- of toepassingenarchitectuur) bestaat uit het definiëren van delen van systeemfunctionaliteit zodanig dat een deel bij meerdere systemen kan worden gebruikt. Waarom het wiel opnieuw uitvinden, als een functionaliteit een standaard is. Een voorbeeld hiervan is de functionaliteit om de printer aan te sturen. Het doel van een applicatiearchitectuur is verhoging van de efficiency van de systeemontwikkeling. Gegevensarchitectuur bestaat uit het definiëren van gegevens op een wijze dat een gegeven door verschillende systemen kan worden gebruikt. Neem bijvoorbeeld het definiëren van het gegeven ‘persoon’. Definitievragen die aan de orde komen zijn: Nemen we alleen natuurlijke personen op? Welke set van gegevens hoort tot ’persoon’? Hoe worden voorvoegsels verwerkt? Et cetera. Het doel van een gegevensarchitectuur is het gemeenschappelijk gebruik van gegevens door de informatiesystemen.

bedrijfsstrategie (alignment). De auditor zal bij een audit aan dit punt expliciet aandacht geven. In het normenstelsel dat in dit artikel is opgenomen is er sprake van slechts één norm op dit punt, namelijk ‘wordt bij aanvang van het modelleren van de architectuur rekening gehouden met de bedrijfsstrategie?’ Boer & Croon hebben hiervoor een denkmodel ontwikkeld. Het denkmodel werkt als een communicatiemiddel naar het topmanagement. Het legt namelijk de relatie tussen een informatiearchitectuur en met voor het topmanagement bekende elementen als strategie en organisatie. De boodschap voor het topmanagement is: Architectuur lijnt strategie, organisatie en ICT uit. Het model laat ook zien dat er sprake is van elkaar beïnvloedende entiteiten. Een veranderende strategie raakt de organisatie en de ICT. Architectuur helpt om dat inzichtelijk te maken en daardoor veranderingen te vergemakkelijken. Het denkmodel van Boer & Croon onderscheidt een offensieve én een defensieve toepassing van architectuur. Dit denkmodel kan worden gebruikt als hulpmiddel door degene die informatiearchitectuur als onderwerp met het topmanagement gaat bespreken. Voor de auditor kan het ook een hulpmiddel zijn bij zijn onderzoek. De begrippen offensieve en defensieve toepassing van architectuur worden hierna toegelicht.

Technische architectuur bestaat uit: • de databasearchitectuur – dit heeft te maken met de technische inrichting van de databases; • de apparatuurarchitectuur – dit heeft te maken met de technologie waarmee de systemen draaien; • de communicatiearchitectuur – dit heeft te maken met de wijze waarop systemen met elkaar en met de gebruikers kunnen communiceren.

Strategie

Alignment In de inleiding is geschetst dat managers de noodzaak ervaren dat systemen flexibel zijn en snel en tegen relatief geringe kosten kunnen worden aangepast. Losjesweg heb ik geconcludeerd dat dit eisen stelt aan het systeemontwerp en daardoor zelfs aan de informatiearchitectuur. Maar hoe komt het belang van een informatiearchitectuur voor het voetlicht van het topmanagement? Hierbij gaat het erom dat de ICT-manager duidelijk kan maken dat de informatiearchitectuur ondersteunend dient te zijn aan de

- Ambitie

Architectuur - Structuur

- Uitgangspunten - Mogelijkheden

Doel is het verbeteren van de toepasbaarheid en het verhogen van de flexibiliteit van het gebruik van de systemen. De technische architectuur wordt in dit artikel niet verder uitgewerkt.

11

- Huidige infra

- Regels ICT

- Afspraken

Organisatie

- Cultuur (normen, waarden, gewoonten) - Autonomie - Verandering

Figuur 1. Denkmodel volgens Boer & Croon Offensieve toepassing van architectuur Het topmanagement is vooral geïnteresseerd in de wijze waarop de bedrijfsstrategie kan worden behaald en hoe de informatiearchitectuur daarbij ondersteunend kan zijn. In het maken van de strategische keuzes dienen afwegingen te worden gemaakt die alleen het topmanagement kan maken. De informatiearchitectuur zal van deze keuzes dienen te worden afgeleid. Het topmanagement zal de consequenties van haar keuzes voor de informatiearchitectuur moeten kennen. Dit klinkt misschien wat abstract. Daarom volgen enkele

12


voorbeelden van strategische keuzes die van invloed zijn op de architectuur van de (toekomstige) systemen om het te verduidelijken: • Een onderneming wil enerzijds sterk groeien (omzetverdubbeling binnen drie jaar) door middel van acquisities en anderzijds ICT standaardiseren. Rijmt dit? • Een onderneming wil binnen drie jaar 90% van haar inkopen via het internet doen. Een vergeten vraag hier is: Waar leg je de verantwoordelijkheid voor het datamanagement van de grondstofgegevens? Bij de leveranciers of intern in de eigen organisatie? • Een onderneming wil de huidige situatie van lokale autonomie handhaven, maar wil tevens iets aan eBusiness doen. Er moet wel één gezicht naar buiten worden getoond. Hoe doe je dat? • ICT heeft de tendens te centraliseren, mede ingegeven door kostenoverwegingen. Past dit wel in de cultuur van de onderneming? Wat leg je dan centraal (synergievoordeel) en wat decentraal? Het aansluiten bij specifieke thema’s die leven bij het topmanagement is essentieel. De informatiearchitect communiceert erover hoe de informatiearchitectuur een rol speelt in deze thema’s. Hij laat zien hoe de architectuur ondersteunend is aan de strategische wensen van het management, maar misschien ook dat bepaalde strategische wensen met elkaar conflicteren. De conclusie luidt dat de informatiearchitect in de communicatie met het topmanagement over informatiearchitectuur veel aandacht zal moeten besteden aan de relatie met strategie en organisatie. Het aangeven van deze relatie is nodig om architectuur bij het topmanagement op de kaart te zetten. Defensieve toepassing van architectuur Het tweede motief om een informatiearchitectuur te ontwikkelen is de behoefte aan beheersing van (de gevolgen van) de complexiteit van de IT. Dit beheersingsprobleem wordt veroorzaakt door de veelvormigheid en omvang van de voorzieningen, maar ook door grote dynamiek in het aanbod. De belangrijkste missie bij de uitvoering van architectuur is die van richting geven aan en faciliteren van de ontwikkeling van de informatiehuishouding en van informatiesystemen. Om de complexiteit het hoofd te bieden moet de ICT-discipline op verschillende manieren de complexiteit te lijf. In de hele keten van het interne IT-bedrijf moet een proces op gang worden gebracht om de complexiteit te beperken en te beheersen. Dit begint met een bewustwording en een juiste perceptie van het probleem dat complexiteit met

zich meebrengt en als eerste moeten strategieën worden ontwikkeld, waarmee de complexiteit kan worden aangepakt. Deze strategieën kunnen zijn [HAMM98]: • het voorkomen van onnodige complexiteit; • het reduceren van de complexiteit van het bestaande en het nieuwe; • het toegankelijk maken van complexe concepten en de kennis/informatie over IT-voorzieningen; • het communiceren van de complexiteit om het bewustzijn daarvan te creëren. Het doel hiervan is bij te dragen aan de besluitvorming en realistische verwachtingen te scheppen. Hiermee is de ’defensieve’ rol van de informatiearchitectuur bepaald. De beperking van risico’s, veroudering, redundantie en ondoorzichtigheid zijn overheersend. De missie van de IT-functie in het bedrijf is om uit het aanbod aan IT-middelen en diensten op de langere termijn een stabiele, state-of-the-art, waardevaste, veilige, transparante, betrouwbare, schaalbare, koppelbare en ook nog kosteneffectieve structuur te bouwen. Voorwaar een ambitieuze doelstelling! Nadat de behoefte aan beheersing heeft geleid tot het organiseren van een alignmentfunctie en een architectuurdiscipline ontstaan concepten, richtlijnen en afspraken op hoog niveau over oplossingen, verantwoordelijkheden en processen. In een bewust uitgevoerd alignmentproces worden innovaties ontwikkeld en gestuurd vanuit een visie op de gewenste inrichting van de informatievoorziening, die via architectuurprocessen is uitgewerkt. Het bedrijfsmanagement is hierbij sterk betrokken.

Ontwikkeling informatie architectuur

Business eisen (High level) systeemeisen (High level) performance eisen

Systeemontwerp Componenten en services Interfaceontwerp Productkeuzen Ontwerprichtlijnen Ontwerpbeslissingen

Stakeholders

Systeem

Systeemontwikkeling

Organisatie Personeel Procedures

Figuur 2. Informatiearchitectuur in zijn context


Architectuur- vs. systeemontwikkeling Zoals uit figuur 2 blijkt, liggen de ontwikkeling van een informatiearchitectuur en van een systeem in elkaars verlengde. De informatiearchitectuur vormt immers de basis voor het te ontwikkelen systeem en uiteindelijk voor meerdere systemen. De ontwikkeling van een systeem zal aansluiting moeten vinden op de informatiearchitectuur. En deze aansluiting verloopt niet altijd even vlekkeloos. Er zijn enkele aandachtspunten die hierbij een rol spelen. Deze aandachtspunten zijn voortgekomen uit eigen ervaring bij een groot architectuurproject – dat helaas mislukt is – en strookt met ervaringen van anderen [DISS00]. Vervolgens doe ik enkele suggesties om de genoemde aandachtspunten te kunnen hanteren. Aandachtspunten Gescheiden projecten Het realiseren van een informatiearchitectuur en de systeemontwikkeling worden vaak in verschillende projecten uitgevoerd of zijn verschillende fases in één project. Dit kan een aantal complicaties tot gevolg hebben: • De mensen die aan de informatiearchitectuur gewerkt hebben zijn weg als er begonnen wordt met het systeemontwikkelingtraject. Voor een hedendaagse systeemontwikkelaar is het vaak belangrijk om te weten waarom bepaalde beslissingen genomen zijn. Om te vermijden dat beslissingen gedurende het ontwikkeltraject in twijfel worden getrokken (en dan ter discussie staan) en om commitment bij de systeemontwikkelaar te verhogen, is het belangrijk dat men inzicht krijgt in het hoe en waarom van beslissingen. • Het is lastig, zo niet onmogelijk, om een informatiearchitectuur neer te zetten die genoeg diepgang en detail heeft zonder de systeemarchitectuur of cruciale delen ervan te testen of te prototypen. Vaak blijkt, dat om uiteenlopende redenen een ontwerpbeslissing niet juist is geweest. Daarbij komt, dat bij de informatiearchitectuur meestal wordt uitgegaan van een ideale situatie en afwijkingen hierop meestal zijn ingegeven door de omstandigheden van de niet ideale praktijk. De architectuur wordt immers pas daadwerkelijk getest in de ontwikkelen uitrolfase. Miscommunicatie De communicatie tussen architecten en ontwikkelaars verloopt niet altijd even vlekkeloos als er al van communicatie sprake is. Miscommunicatie speelt zich af op een aantal vlakken en heeft verschillende oorzaken: • Het gebruik van verschillende methoden en technieken die niet op elkaar aansluiten is niet bevorderlijk voor de overgang van informatiearchitectuur naar systeemont-

wikkeling. De meeste tools zijn niet in staat om alle facetten van architectuur en ontwikkeling af te dekken. Als er verschillende tools worden gebruikt, kijk dan of ze onderling interoperabel te maken zijn. Ook de introductie van een ‘nieuwe’ manier van systeemontwikkeling legt een extra druk op de informatiearchitectuur. • Begrippen en definities worden door de twee disciplines vaak verschillend geïnterpreteerd. Mismatch van producten Architectuur is een relatief jonge loot aan de ICT-boom. Over de definitie van architectuur is nog geen overeenstemming binnen de ICT-gemeenschap. Laat staan over producten die de architectuur op zou moeten leveren aan de systeemontwikkeling. Het risico is aanwezig dat het eindproduct van de architectuur niet als startpunt van de ontwikkeling van het beoogde systeem kan dienen. De architectuur heeft niet de mate van detail waarmee richting kan worden gegeven aan de systeemontwikkeling. Dit is funest als de ontwikkeling van een informatiearchitectuur en de ontwikkeling van een systeem in de tijd gescheiden projecten zijn. Gebruikers zijn niet betrokken Het risico is aanwezig dat gebruikers niet bij het architectuurproject betrokken worden. Voor de gebruikers is een architectuur begrijpelijkerwijs abstract. De architectuur is in het eindresultaat, de applicatie, transparant. Toch is de inbreng vanuit de gebruikersorganisatie belangrijk. Waarom? De feitelijke kennis over een (toekomstig) systeem zit bij de gebruiker. Hij zal in deze fase al input moeten leveren op het gebied van de gewenste functionaliteit en de benodigde gegevens. In deze fase wordt echter nog geen functioneel ontwerp gemaakt. Toch is kennis over de functionaliteit en gegevens nodig. Met deze kennis zal gezocht moeten worden naar gemeenschappelijke functionaliteit en gegevensgebruik. Suggesties Hier volgen suggesties in verband met de aandachtspunten die hiervoor zijn genoemd. Continuïteit Het probleem van verschillende projecten of gescheiden trajecten kan eenvoudig worden opgelost door ervoor te zorgen dat enkele personen die geparticipeerd hebben in het architectuurtraject beschikbaar zijn tijdens de realisatiefase. Beter nog is het om een aantal personen vanuit de realisatiefase te laten participeren in de architectuurfase. Het spreekt voor zich dat dit geen lichtgewicht ontwikkelaars zullen zijn.

13

14


Architectuur en ontwikkeling parallel Een gedeelte van de architectuur kan parallel worden uitgevoerd met het ontwikkeltraject van het systeem (de realisatiefase). Een parallel traject kan om verschillende redenen worden uitgevoerd: • testen van concepten in de systeemarchitectuur; • validatie bij de gebruikersorganisatie; • aansluiting bij incrementele ontwikkeling; • migratie van een bestaand systeem waarbij delen in de tijd vervangen worden. Spreek dezelfde taal en begrijp elkaar • Dit is vooral van toepassing op de fase van de architectuur die het dichtst bij systeemontwikkeling ligt. De ervaring is dat een optimale situatie verkregen wordt als een systeemarchitect ruime ontwikkelervaring heeft en dat ontwikkelaars vertrouwd zijn met methoden die in de systeemarchitectuur gebruikt worden. Dit laatste kan bijvoorbeeld worden bereikt in de vorm van een introductiecursus. • Op het gebied van methoden en tools kan worden gekeken naar tools die op elkaar aansluiten. • Spreek heel goed af wat het bereik van de architectuur is en wat het bereik van systeemontwikkeling is. • Werk samen. Een architect dient samen te werken met het gehele projectteam. Dit is zeker belangrijk in de fase van de architectuur die het dichtst bij de systeemontwikkeling ligt. Op deze manier wordt er commitment verkregen van de systeemontwikkelaars. Immers, ze werken beiden aan hetzelfde doel. Betrek de gebruikersorganisatie er vroegtijdig bij Zorg voor gebruikers die vrijgemaakt zijn om het architectuurproject te participeren. Zorg er dan ook voor dat in voor gebruikers begrijpelijke taal het doel en de functie van een architectuur wordt uitgelegd. De keuze voor wie in een dergelijk project kan participeren, zal niet altijd eenvoudig zijn. Het zullen gebruikers moeten zijn met veel kennis over de applicaties en met affiniteit voor automatisering. In een organisatie zijn dit al vaak de medewerkers waar zwaar op wordt gesteund. Al met al zijn dit geen vernieuwende suggesties. Toch blijkt in de praktijk dat ze weerbarstig genoeg zijn. Het is raadzaam om ook over deze eenvoudige tips van te voren na te denken en er een oplossing voor te vinden.

tuur kan worden getoetst. Het hoofdstuk wordt afgesloten met een conclusie. Aan het eind van het artikel heb ik een normenset geformuleerd dat als hulpmiddel kan worden gebruikt. Wat is kwaliteit? In studierapport nummer 2 van de NOREA getiteld ’Een kwaliteitsmodel voor Register EDP-auditors’ wordt gezegd: ’kwaliteit is nooit een incident, het is altijd het resultaat van een intelligente samenwerking’. [NORE97] Deze definitie geeft aan waar het om gaat bij kwaliteit. Kwaliteit is geen incident, als zou het om een toevalligheid gaan. Kwaliteit is iets wat doelbewust moet worden nagestreefd. Kwaliteit is het resultaat van samenwerking. Ook bij het maken van een informatiearchitectuur gaat het om een nauwe samenwerking tussen de verschillende stakeholders. In de definitie is sprake van ’intelligente’ samenwerking. Dit betekent in de context van architectuur dat bij het maken van een architectuur rekening wordt gehouden met de (interne) omgevingsfactoren, het creëren van draagvlak en het verzorgen van een goede communicatie. Dit alles is al aan de orde gekomen. De kwaliteit van een informatiearchitectuur kan als volgt worden gedefinieerd: De kwaliteit van een informatiearchitectuur is het vermogen van een architectuur de niet-functionele eisen aan de te bouwen systemen te ondersteunen. Wanneer is een architectuur goed? Of anders gezegd wanneer is een architectuur goed genoeg? In deze context is ‘goed’ een betrekkelijk begrip, want om een architectuur te kunnen beoordelen, moeten we eerst de criteria vaststellen op basis waarvan we dat kunnen doen. Deze criteria zijn namelijk sterk afhankelijk van het doel wat met de architectuur wordt beoogd. Op basis van het doel kunnen de bijbehorende criteria en normering worden gedefinieerd waarop de resultaten worden beoordeeld. Door verschillende partijen zijn methodieken ontwikkeld om de validatie van de architectuur uit te voeren. In dit hoofdstuk zullen deze hulpmiddelen de revue passeren. Dit zijn achtereenvolgens: • Architecture Score Card van Cap Gemini; • architectuurreview van het Software Engineering Research Centre; • de architectuurbenadering van ATOS Origin.

Kwaliteit van architectuur Hoe kun je als auditor de kwaliteit van een architectuur toetsen? In dit hoofdstuk worden drie verschillende hulpmiddelen besproken waarmee de kwaliteit van architec-

Architecture Score Card™ De Architecture Score Card [ARCH00] is gebaseerd op een methodologische benadering van de verschillende architectuurproducten die voortkomen uit verschillende


Figuur 3. Relatie tussen architectuurgezichtspunten, aspectgebieden en abstractieniveaus architectuurprocesstappen. Op basis van een vooraf gedefinieerde normering voor alle architectuuraspectgebieden kan eenvoudig worden vastgesteld of de architectuurproducten aan de criteria voldoen. Alvorens in te gaan op de nadere details van de Architecture Score Card is het goed om de belangrijkste processtappen die hierbij worden gehanteerd te leren kennen. Cap Gemini heeft de aspectgebieden en de abstractieniveaus binnen het geïntegreerde architectuur raamwerk (IAF), verder uitgewerkt in een aanpak – Cap Gemini’s Integrated Architectural Approach (IAA). In deze benadering worden naast de genoemde architectuuraspectgebieden de vijf procesfaseringen onderscheiden, die in de IAA-aanpak vaak overeenkomen met de vijf abstractieniveaus: • Contextuele fase: wat zijn de missie en doelen van de organisatie, hoe wenst de organisatie te functioneren in zijn omgeving en hoe ziet de omgeving van de organisatie eruit, wat is de omvang van het architectuurtraject? • Conceptuele fase: wat zijn de randvoorwaarden, uitgangspunten, eisen en beperkingen die betrekking hebben op het architectuurtraject en die worden gesteld aan de architectuur? Een conceptueel architecturaal ontwerp. • Logische fase: hoe kan de oplossing worden gerealiseerd, een logisch architecturaal ontwerp? • Fysieke fase: waarmee kan de oplossing worden gerealiseerd, een fysiek architecturaal ontwerp? • Transformatie fase: wanneer kan de oplossing worden geïmplementeerd en wat is de impact op de organisatie en de ICT-omgeving? De methodiek achter de Architecture Score Card maakt gebruik enerzijds van de architectuuraspectgebieden en anderzijds van de verschillende procesfaseringen. Op basis van deze benadering is een meetmethodiek ontwikkeld die inzicht geeft in en overzicht geeft van de kwaliteit van een te beoordelen architectuur. Op basis van vragen over de aspectgebieden en de procesfasen wordt vastgesteld in welke mate de architectuur aan een aantal

criteria voldoet. Hierdoor kan een goed inzicht en overzicht worden verkregen van de kwaliteit van een architectuur. Specifiek wordt door de leverancier van het tool aandacht gevraagd voor de onderhoudbaarheid van de architectuur. Van belang daarbij is of de resultaten van de architectuurstudie op een zodanige manier zijn gedocumenteerd dat deze ook op de langere termijn onderhoudbaar zijn, ook door andere architecten dan de oorspronkelijke architecten. Het element van onderhoudbaarheid dient dan ook in de overall-beoordeling te worden meegenomen. Architectuurreview door het SERC Een tweede benadering is die van het Software Engineering Research Centre (SERC) [ZEIS96]. Door hen is een aanpak van architectuurreview ontwikkeld. Deze aanpak gaat uit van het toetsen van een architectuur aan de kwaliteitsattributen uit het Quint2/Extended ISO 9126 model. Het is de verantwoordelijkheid van de softwarearchitectuur om richting en (gedeeltelijke) invulling te geven aan de kwaliteitseisen die worden gesteld aan een systeem. Het SERC hanteert de Engelse terminologie. Afhankelijk van de bedrijfscultuur waar het model wordt toegepast, dienen de termen te worden overgezet naar de Nederlandse taal. De specifieke aanpak van een architectuurreview is erg afhankelijk van de situatie. Een belangrijke factor hierbij is het doel van de architectuurreview. De nadruk kan liggen op: • het bepalen van de kwaliteitseisen die aan een architectuur in ontwikkeling worden gesteld; • het bepalen van de kwaliteit van een architectuur en de bijbehorende artefacten; • het bepalen van de impact van wijzigingen op een architectuur. Om deze doelen te verwezenlijken kan een aantal middelen worden ingezet zoals workshops, interviews, productstudies en experimenten.

15

16


Functionality

Maintainability

Usability

Reliability

Portability

Suitability

Analyzability

Understandability

Maturity

Adaptability

Time-behavior

Accuracy

Changeability

Learn ability

Fault

Installability

Resource behavior

Interoperability

Stability

Operability

Tolerance

Conformance

Compliance

Testability

Explicitness

Recoverability

Replaceability

Security

Manageability

Customizability

Availability

Traceability

Reusability

Attractiveness

Degradability

Efficiency

Clarity Helpfulness

Figuur 4. Kwaliteitsattributen in het Quint2/Extended ISO 9126 model Een workshop heeft tot doel de (kwaliteits)eisen die aan het systeem worden gesteld in kaart te brengen en dient daarom te worden bijgewoond door alle bij het systeem betrokken partijen/stakeholders. Een workshop kan ook worden gebruikt om toekomstige wijzigingsscenario’s te bepalen. Interviews worden gebruikt om het beeld van de verschillende partijen van de architectuur te bepalen en om de te toetsen eigenschappen van de architectuur in kaart te brengen. Het voordeel van interviews is dat betrokkenen sneller geneigd zijn hun opinie over het systeem te geven. Het doel van een productstudie is om de kwaliteit van de architectuur en de bijbehorende documenten en producten te bepalen. Experimenten en prototypes kunnen de haalbaarheid van oplossingsrichtingen toetsen. Ook kunnen experimenten en prototypes worden gebruikt om belangrijke verbeteringen in bestaande knelpunten te demonstreren. De architectuurbenadering van ATOS Origin De derde benadering is de architectuurbenadering van ATOS Origin [POST]. In feite is deze benadering ook een review op de architectuur die wordt uitgevoerd door consultant/architecten. Toch kan ik mij voorstellen dat er ook een beroep wordt gedaan op een IT-auditor omdat hij een onafhankelijke partij is. De werkwijze is interessant genoeg om in dit artikel op te nemen. De uitvoering van deze methode kan als eventueel advies worden gegeven of de IT-auditor kan de onafhankelijke rol die in deze benadering wordt genoemd, op zich nemen. De methodiek benadert de vraag waarom de relatie tussen de niet-functionele eisen en een architectuur zo lastig te bepalen is met de invalshoek van organisatieverandering. Een succesvolle organisatieverandering stoelt op drie pijlers, namelijk techniek, politiek en cultuur. Vanuit technisch perspectief kan worden gezegd dat er inderdaad nog veel te leren is over de beïnvloeding van de niet-functionele eisen en de architectuur. Architectuur-

ontwikkeling lijkt nog teveel te worden gedaan op basis van intuïtie en ervaring van de architecten. Het speelt zich nog veel af in het hoofd van de architect en is nauwelijks objectief meetbaar. Tools en technieken voor architectuurassessments zijn nog niet verkrijgbaar. Architectuurbesluiten zijn vaak niet gedocumenteerd. Rond architectuur ontwikkelen zich ook ‘politieke’ invloeden. Dit is het logische gevolg van het feit dat een architectuur een strategisch belang heeft. Er zijn veel stakeholders bij betrokken terwijl een architectuur weinig zichtbaar is en vaak als abstract wordt ervaren. Er is een culturele beperking bij het leggen van een link tussen de niet-functionele eisen en de architectuur. Binnen organisaties is weinig bewustzijn voor de onderlinge relaties tussen afdelingen en werkzaamheden door de afdelingen. Iedere afdeling (marketing, productie, service, IT) ziet het maken van een architectuurproduct als niet transparant. Dit resulteert erin dat het (midden)management niet echt geïnteresseerd is in het definiëren van de nietfunctionele eisen. Doel van de architectuurbenadering is een systematische benadering van de architectuurmodellen waarbij de deelname van de stakeholders het uitgangspunt is. Doelstelling is de kwaliteit van de architectuur te bepalen en de mogelijkheden voor verbetering te identificeren. Kwaliteit is hierbij het vermogen van de architectuur in het realiseren van de niet-functionele eisen. Door het uitvoeren van het voorgestelde assessment in een vroeg stadium in het ontwikkelproject verkrijgt het management goed gedocumenteerd inzicht in de risico’s van de architectuur. Het moment dient zo gekozen te zijn dat correctieve acties tegen beperkte kosten mogelijk zijn. De basisfilosofie achter de assessment is een zelfevaluatie geleid door een externe partij. De architecten zelf en de andere stakeholders moeten de kwaliteit van de architectuurmodellen bepalen. De taak van de externe expert is


het assessment faciliteren. Zij vormen niet zelfstandig een oordeel over de architectuur; dit is alleen mogelijk met veel kennis van het applicatiedomein. Het assessment kent een aantal fasen. De volgende fases zijn te onderscheiden: Consensus over de eisen Identificeer de niet-functionele eisen en de prioriteiten door de stakeholders te interviewen. Deze interviewronde wordt gevolgd door een plenaire sessie met als doel consensus vast te stellen of te bereiken. De externe partij leidt de interviews en de plenaire sessie. De architecten spelen een meer passieve rol als geïnterviewden, net zoals de stakeholders van het management van marketing, productie, systeemontwikkeling, servicemanagement enzovoort. Analyse van de architectuur Dit is de fase waarin de architectuur wordt aangelegd tegen de niet-functionele eisen waarover het management het eens is. De architectuurbeslissingen worden geïdentificeerd en gerelateerd aan de eisen. Op deze manier kan worden bepaald in welke mate de architectuur de eisen ondersteunt. Dit wordt uitgevoerd door de architecten. Architectuurreview De resultaten uit de vorige fase worden gepresenteerd en bediscussieerd in één of meerdere plenaire sessies. Deze worden geleid door de externe partij. De sterke en zwakke elementen van de architectuur, risico’s en voorstellen van verbetering worden besproken. Dit is het belangrijkste onderdeel van het geheel. De resultaten van de interviews en de analyse komen hier samen, worden openlijk bediscussieerd en zal (moeten) leiden tot consensus over de kwaliteit van de architectuur en de eventuele uit te voeren verbeteringen. Rapportage De resultaten uit de vorige fase worden vastgelegd in een rapport. Dit rapport wordt gepresenteerd en wederom bediscussieerd in een plenaire sessie met daarin alle betrokkenen, inclusief het management. Deze fase wordt uitgevoerd door de externe partij. Hoe komt deze benadering tegemoet aan de eerder genoemde drie pijlers techniek, politiek en cultuur? De technische rationaliteit zal sterk worden vergroot door een systematische benadering op tafel te brengen die de nietfunctionele eisen expliciet en meer grijpbaar maken. Uiteindelijk worden ze allemaal bediscussieerd, gedefinieerd, gegroepeerd, geprioriteerd en toegekend in een open proces waarin veel experts hun zegje kunnen doen. Op deze manier worden veel van de overwegingen van de architecten die in

eerste instantie in hun hoofden zitten, gebaseerd op ervaring en intuïtie, expliciet voor alle andere betrokkenen gemaakt. Politieke tegenstand is een onderdeel van een bedrijf en kan zich sterk laten gelden rond architectuurproducten. Welke systematische benadering er ook is, dit is moeilijk te bestrijden. Als mensen niet willen participeren in een open discussie is het moeilijk hen aan tafel te krijgen. Desalniettemin, zaken zijn meestal niet zwart of wit. Het gebruik van een systematische benadering, maar ook de aanwezigheid van een externe partij kan helpen de spanning te reduceren. Het wordt moeilijker voor mensen de discussies te domineren of zelfs te manipuleren. Dit kan anderen weer aanmoedigen vrijer te spreken. Achterkamertjesgeregel en misbruik van macht zullen moeilijker zijn in dit proces. Voor het culturele perspectief is het duidelijk dat deze benadering leidt tot een toegenomen besef van de belangrijkheid van goede architectuurproducten. Zowel het management als de architecten raken betrokken in dit proces en zullen veel kunnen leren over de architectuur. Mensen krijgen een open uitnodiging om deel te nemen in de discussies en bij te dragen aan nieuwe ideeën. Conclusie bij deze drie methoden De Architecture Score Card geeft inzicht in de verbindingen tussen strategie en uitvoering enerzijds en de verschillende aspectgebieden anderzijds. De architectuurreview van het SERC is gericht op de eisen waaraan een informatiearchitectuur moet voldoen. De architectuurbenadering van ATOS Origin voegt daaraan toe de actieve participatie van stakeholders. Iedere van de genoemde methoden heeft zijn eigen invalshoek en zo vullen ze elkaar aan. De architectuurbenadering van ATOS Origin sprak mij aan. Hij lijkt op de knelpuntenanalyse projectmanagement zoals die in het handboek EDP-Auditing staat beschreven [SWIN]. In de praktijk heb ik daar zeer positieve ervaringen mee opgedaan. Met een relatief kleine investering komen de sterke en zwakke punten van het projectmanagement duidelijk naar voren. Projectmanagement is geen architectuur. Maar ook bij projectmanagement spelen cultuur en politiek een belangrijke rol. Ervaring en intuïtie van de projectleider vormen ook nog wel eens de basis voor de genomen besluiten. Door deze overeenkomsten verwacht ik dat deze architectuurbenadering goede resultaten kan opleveren.

Normen Normen voor het informatiearchitectuurproduct 1. Opdrachtgever en -nemer hebben overeenstemming over de ‘eisen aan de architectuur’, uit te splitsen naar: • afbakening van het systeem, van het ‘object’ van de architectuur.

17

18


Voorbeelden zijn: - alle processen, informatie-items, actoren en technologie-items gerelateerd aan de afdeling ‘Marketing & Sales’; - alle processen, informatie-items en actoren ondersteund door de softwareapplicaties die onder UNIX draaien; - alle processen, actoren en technologie gerelateerd aan klantinformatie; - de eisen aan dat systeem; - de wijze van beschrijving van het systeem en van de eisen daaraan. 2. De opdrachtgever dient aan te geven welke eisen aan dat systeem in de architectuur dienen terug te komen. De kwaliteitseisen in het model van het SERC kunnen hierbij een hulpmiddel zijn. Er zullen ook investeringseisen zijn, zoals: • kosten: eisen aan de kosten van het maken, onderhouden en exploiteren van het systeem; • baten: eisen aan de baten van het maken, onderhouden en exploiteren van het systeem; • risico’s: eisen ten aanzien van de getolereerde risico’s voor en als gevolg van het maken, onderhouden en exploiteren van het systeem. 3. De architectuur moet laten zien binnen welke eisen en randvoorwaarden ontwerpbeslissingen kunnen worden genomen. 4. Specifiek voor de gegevensarchitectuur: • Standaardisering van de betekenis van gegevens, dat wil zeggen ontdoen van de willekeur van de specifieke situatie. Het doel van de betekenisstandaardisatie is het verkrijgen van een ondubbelzinnige en uniforme betekenis van de bedrijfsgegevens. Het gebruik van gegevens voor meer doeleinden vereist een uniform gedefinieerde betekenis, dit wil zeggen ongeacht: - de representatievorm op media; - het gebruik; - het toepassingssysteem dat het betreft; - de organisatorische eenheden die de gegevens gebruiken of beheren. • Standaardisering van de vorm. Deze vormstandaards hebben betrekking op: - de schrijfwijze en maximale lengte van gegevenselementen; - de externe representatie van de gegevens. Dit leidt tot de keuze van codestelsels (bijvoorbeeld de ISOmuntcode). De interne representatie hoeft niet uniform te zijn. Gemeenschappelijk gebruik impliceert wel éénmaal waarnemen, verzamelen en registreren, maar niet noodzakelijk éénmaal opslaan; - de gewenste kwaliteit van de gegevens. Daarbij gaat het om de volgende aspecten:

Δ de juistheid en betrouwbaarheid; Δ de volledigheid van de gegevensverzameling; Δ de actualiteit. Hieronder wordt verstaan de tijd die verstrijkt tussen het plaatsvinden van een relevant feit en het moment waarop dat leidt tot een wijziging in de administratie; Δ de toegankelijkheid. • Koppel belang en verantwoordelijkheid = definieer, structureer en verzamel alleen gegevens die ook daadwerkelijk gebruikt gaan worden, zodat in het gebruik een gebrek aan kwaliteit tijdig kan worden opgemerkt. Leg de verantwoordelijkheid voor de gegevens en de gegevensbeschrijvingen bij degene die het grootste belang heeft bij de kwaliteit ervan. In geval van gemeenschappelijk gebruik van gegevens leg je de bevoegdheid en verantwoordelijkheid van de gegevens zoveel mogelijk bij degene die de hoogste eisen stelt aan de kwaliteit van de gegevens. • Gegevensbeheersystemen dienen een zodanige structuur te hebben dat ze gemakkelijk uit te breiden zijn. Een groeiscenario ligt hieraan ten grondslag. Zodra een nieuw applicatiesysteem ontwikkeld wordt, leidt dit zonodig tot aanpassingen en tot uitbreiding van de standaards. • Maak voor de juistheid van elk gegeven precies één organisatorische functie of eenheid verantwoordelijk. Dit is de functionele beheerder. De functionele beheerder is de enige die gemachtigd is een gegeven op te voeren, te wijzigen of te verwijderen. Bij toewijzing van het functioneel beheer gelden de volgende richtlijnen: - voor resultaatgegevens is degene verantwoordelijk, die het resultaat, waarop het gegeven betrekking heeft, tot stand brengt; - voor gegevens die afkomstig zijn uit de omgeving is degene verantwoordelijk voor wie vooral de kwaliteitseisen met betrekking tot actualiteit en volledigheid van het grootste belang zijn, ofwel degene die het gegeven als eerste nodig heeft. Een alternatief is de verantwoordelijkheid leggen bij degene die het grootste belang heeft bij de juistheid van het gegeven. Ook combinaties van beide zijn mogelijk. 5. Specifiek voor de gegevensarchitectuur De functionaliteit van een te bouwen architectuur dient volgens de volgende afbakeningscriteria opgedeeld te zijn: • relatieve autonomie: dit wil zeggen een clustering van processen met een sterke interne samenhang en zwakke koppeling met andere clusters van processen; • zelfstandig bestaansrecht: dit wil zeggen dat het (deel)systeem een bestaansrecht heeft onafhankelijk van andere (deel)systemen;


• projectmatige realiseerbaarheid: dit wil zeggen dat er een zodanige afbakening van het (deel)systeem is dat het ontwikkelingstraject op een succesvolle wijze is af te ronden. De volgende factoren bepalen het succes van projecten: - duidelijkheid van de doelstellingen; - kennis en ervaring met de toe te passen methoden; - kennis en ervaring met de toe te passen technieken; - omvang en complexiteit van het (deel)systeem.

• aspectgerichtheid: voor de beoordeling van de methode is het van belang welke aspectmodellen worden onderkend en hoe ze worden gebruikt. Literatuur [ARCH00] Architectuur en Infrastructuur (2000), nr. 4. [BURG]

Burg, H., Volwassenheid in een architectuurorganisatie.

[DISS00]

Disseldorp, J. van, A. Hendriks, R. Spijkerman en H. Vader (2000), Architectuur vs. realisatie -

Normen voor het proces bij tot stand brengen architectuurproducten 1. Vanaf aanvang van het architectuurproject dient rekening te worden gehouden met de bedrijfsstrategie en zullen de eventuele gevolgen voor de te ontwikkelen architectuur inzichtelijk gemaakt zijn. 2. Het (top)management dient vanaf de start van het architectuurproject actief erbij te worden betrokken. 3. Er zijn maatregelen getroffen om de kennis over de architectuur en ontwerpkeuzes te borgen. Denk hierbij aan: • ontwikkelaars zowel in de architectuur- als de realisatiefase laten participeren; • ontwikkelen en gebruiken van documentatiestandaards; • structureren van het keuzeproces in de architectuurfase. 4. In algemene zin dienen de juiste partijen te worden betrokken. Hierbij dient de gebruikersorganisatie niet te worden vergeten. 5. De ontwerpstrategie zal moeten voldoen aan twee belangrijke criteria: • de complexiteitsvermindering in de modellering: dat wil zeggen dat de werkelijkheid voldoende is vereenvoudigd om een overzicht te bieden en tegelijkertijd voldoende complex is om alle relevante delen van de werkelijkheid weer te geven. • de verifieerbaarheid van de modellen: dat wil zeggen dat de gebruiker aangeeft of de gewenste toekomstige situatie correct is uitgebeeld. Hiervoor is het nodig dat de gebruiker de modellen kan begrijpen en beoordelen. Deze bovenstaande criteria zijn te globaal om op basis hiervan methoden te toetsen. Hieronder volgt een aantal meer gedetailleerde criteria: • herhaalbaarheid: wanneer de activiteit nogmaals wordt uitgevoerd, moet hetzelfde product ontstaan, ongeacht de persoon die het werk verricht; • onderbouwing: de keuzen die in het modelleringsproces zijn gemaakt, dienen gemotiveerd en verifieerbaar te zijn; • doelgerichtheid: de methode dient aan te geven hoe de bedrijfsdoelstellingen moeten worden vertaald naar systeemeisen;

Ervaringen, Problemen en Aanbevelingen. [HAMM98] Hammer, D.K. (1998), Architectuur belangrijkste middel om complexiteit te bedwingen, in: Automatiseringsgids, 30 oktober. [NORE97] NOREA (1997), Studierapport nr. 2 – Een kwaliteitsmodel voor Register EDP-auditors – De eerste stap, juli. [POST]

Postema, H. en H. Akkermans, Managing architectural risks in product development – a casestudy from the electronics industry.

[SAND97] Sanden, W. van der en B. Sturm (1997), Informatiearchitectuur – de infrastructurele benadering, pp. 23-25. [SWIN]

Swinkels, G.J.P. en L.J.M.W. Gielen, Handboek EDP-auditing B 5.1.1.1. Knelpuntenanalyse projectmanagement, NOREA.

[VREV94]

Vreven, A.A. (1994), Methoden en hulpmiddelen voor de systeemontwikkeling pp. 38-40.

[ZEIS96]

Zeist, B. van, et al. (1996), Kwaliteit van software producten, praktijkervaring met een kwaliteitsmodel.

19

20


De Wireless Toolbox van de IT-auditor De beveiliging van een WLAN-netwerk kan complex en uitgebreid zijn. Het beoordelen van de beveiliging van een WLAN-netwerk vereist dan ook een goed gevulde toolbox voor de IT-auditor. De toolbox bestaat voornamelijk uit gratis software op een Linux platform. De IT-auditor heeft echter niet Mauriche Kroos en Robbert Kramer

alleen software nodig: een juiste combinatie van software, hardware en kennis is onontbeerlijk.

Inleiding Dit artikel is een vervolg op het vorige artikel over WLAN-netwerken (de EDP-Auditor 4/2004) en gaat in op het gebruik van tools voor het testen van de beveiliging van WLAN-netwerken (reconnaissance en exploiting). In het vorige artikel zijn vooral de theoretische achtergronden van WLAN-netwerken beschreven. Deze achtergronden worden in dit artikel verondersteld als aanwezige kennis. Aangezien het artikel is geschreven vanuit de achtergrond van het testen van de beveiliging en niet vanuit het treffen van maatregelen, zullen in dit artikel geen maatregelen worden beschreven. In het volgende artikel wordt ingegaan op maatregelen voor het beveiligen van WLAN-netwerken. Hierbij zal eerst de komende tijd duidelijk moeten worden hoe nieuwe beveiligingsprotocollen worden geaccepteerd en geïmplementeerd in WLAN-netwerken door leverancier en gebruikers. In dit artikel worden verschillende tools beschreven voor het testen van de beveiliging van WLAN-netwerken. De lijst met beschikbare tools groeit gestaag, waarbij deze niet alleen binnen Linux, maar ook binnen Windows kunnen worden gebruikt. Een aantal van de Linux tools zijn ook toe te passen binnen Windows door gebruik te maken van emulatie tools (zoals bijvoorbeeld Cygwin). Met deze tools kan men in Windows een Linux commandoregel emuleren (vergelijkbaar met een ‘DOS box’). De auditor is hierdoor

R.P. Kramer RE is projectmanager bij Ernst & Young EDP Audit en in dienst sinds 1998. Ing. M.R. Kroos RE is manager bij Ernst & Young EDP Audit als EDP-auditor en in dienst sinds 1999.

in staat bepaalde Linux tools binnen Windows te kunnen uitvoeren, zonder dat daarbij een complete installatie van Linux nodig is. De beschreven tools zijn al langer beschikbaar en/of hebben zichzelf min of meer bewezen. Het zijn tools die bij beveiligingstesten veelvuldig worden gebruikt. De doelstelling van dit artikel is duidelijk te maken wat allemaal mogelijk is met tools om de beveiliging van WLAN-netwerken te testen en op basis hiervan te verbeteren en niet om aan te zetten tot het inbreken op WLANnetwerken. Wij wijzen op het feit dat het gebruik van deze tools risicovol kan zijn. Gebruik deze tools alleen in overleg met de opdrachtgever of eigenaar van het WLAN-netwerk en na overeenstemming over eventuele risico’s en de hiermee samenhangende aansprakelijkheid. Tools Het inzetten van tools is bij uitstek de manier om te testen of de getroffen beveiliging rondom WLAN’s werkt zoals verwacht. De IT-auditor heeft bij het testen naast de gangbare zaken, zoals een laptop, de volgende hardware en software nodig: • Diverse WLAN-kaarten die een of meer van de WLANstandaarden (zie vorig artikel) ondersteunt. De in elke WLAN-kaart aanwezige chipset dient te worden ondersteund door de te gebruiken tools. Het dient de voorkeur om gebruik te maken van een netwerkkaart waarop een externe antenne kan worden aangesloten. • Diverse WLAN access points/bridges met tevens de mogelijkheid van het aansluiten van een externe antenne. • Verschillende typen (externe) antennes met voldoende gevoeligheid, die aangesloten kunnen worden op access points en WLAN-kaarten. • De juiste WLAN tools voor de reconnaissance en exploiting fase (zie verderop in dit artikel).


Verder is het belangrijk dat de IT-auditor bekend is met: • het juiste moment voor sniffing, omdat zonder netwerkverkeer niet alle WLAN-netwerken (devices) te vinden zijn; • de wetgeving inzake het toegestane zendvermogen WLAN.

Een handige Linux tool voor het verkennen van de ether is ‘wavemon’. Deze tool geeft onder andere de sterkte van eventueel aanwezige WLAN-signalen weer zoals in figuur 1 duidelijk wordt.

Chipsets kort toegelicht Fabrikanten van WLAN-kaarten maken doorgaans gebruik van gestandaardiseerde chipsets van een beperkt aantal leveranciers. De chipset is het hart van een WLAN-kaart. Het is van belang dat de gebruikte kaarten de juiste chipset hebben om ondersteund te worden door de tool. De auditor zal echter niet kunnen ontkomen aan het (simultaan) gebruik van meerdere kaarten met verschillende chipsets. Momenteel worden de volgende chipsets voldoende ondersteund door tools: • Prism 2 en Prism 2.5/3 • Orinoco/Hermes Silver en Gold • Cisco Aironet • Atheros

Figuur 1. Wavemon voorbeeld

Reconnaissance De reconnaissance (verkennen) van de WLAN-netwerkomgeving is de eerste stap in het testen van de beveiliging. Het doel van de reconnaissance is voldoende informatie achterhalen voor het vervolg in de exploiting fase. Voor het gestructureerd achterhalen van informatie is de reconnaissance opgesplitst in drie stappen, namelijk: • verkennen; • herkennen; • sniffing. Voor iedere stap in de reconnaissance zijn specifieke tools beschikbaar. Verkennen De eerste stap is het verkennen van de ether (het ‘luchtruim’). Hierbij is het de bedoeling om te achterhalen welke signalen aanwezig zijn in het 2.4 GHz en 5 GHz frequentiegebied. Indien WLAN-signalen aanwezig zijn, kan dit betekenen dat WLAN-apparatuur actief is. In dat geval is het zinvol om de volgende stap van het herkennen uit te voeren om vast te stellen wat voor WLAN-signalen en met welke eigenschappen aanwezig zijn. Naam

Wavemon

Soort

Gratis

Platform

Linux

Website

http://www.janmorgenstern.de/project-software.html

Doel

Verkennen ether

Wavemon geeft beperkte informatie over eventuele gevonden WLAN devices maar niet over eventuele aanwezige beveiliging. Daarnaast geeft Wavemon informatie over de aanwezige signaal/ruis-verhouding. Deze verhouding is een indicatie voor de bruikbaarheid van het signaal. Hoe beter de verhouding hoe sterker en zuiverder het signaal. Wanneer Wavemon wordt gebruikt op een laptop die vervolgens wordt verplaatst, dan is het mogelijk in kaart te brengen waar het signaal het meest bruikbaar is. Hierdoor is de optimale testlocatie te achterhalen waarvandaan de test verder kan worden uitgevoerd. Herkennen Het herkennen van WLAN devices is de tweede stap in het testen van de beveiliging van een WLAN-netwerk. Onder WLAN devices wordt verstaan de apparatuur die via WLAN-signalen en standaarden kan communiceren met andere WLAN devices. Dit kan een veelvoud van apparaten zijn: laptops, desktops, PDA’s en handscanners, et cetera. Voor het opsporen van WLAN devices zijn twee verschillende methoden beschikbaar: • Actieve scanning: met de juiste software wordt een bericht de ether ingestuurd (vergelijkbaar met ‘ping’). Indien een WLAN device zo is ingesteld om te reageren op het bericht, zal die een antwoordbericht terugsturen. Dit bericht wordt vervolgens door de betreffende tool opgevangen en geïnterpreteerd. Nadeel van deze methode is dat veel WLAN devices mogelijk niet reageren op deze verzoeken (zie voor nadere uitwerking paragraaf ‘Actieve Scanning’).

21

22


• Passieve scanning: hierbij worden geen berichten de ether ingestuurd, maar ‘luistert’ de tool naar 802.11 verkeer op verschillende kanalen. Actieve scanning Netstumbler Naam

Netstumbler

Soort

Gratis

Platform

Windows

Website

http://www.netstumbler.com

Doel

Herkennen WLAN signalen

Netstumbler is een Windows tool dat WLAN devices in kaart brengt door middel van actieve scanning, zoals in figuur 2 te zien is.

Figuur 2. Netstumbler voorbeeld Een persoon die met Netstumbler naar WLAN devices zoekt, zal echter geen compleet overzicht kunnen samenstellen. De meeste WLAN devices kunnen zo worden ingesteld dat deze niet reageren op ‘ping’-verzoeken. Deze instelling wordt vaak aangeduid als ‘disable broadcast’. De betreffende WLAN devices zullen dan ook niet binnen Netstumbler bekend zijn. Netstumbler kan de gevonden WLAN devices in verschillen categorieën tonen (deze optie heet Filters in het scherm). De volgende categorieën worden gehanteerd: • Encryption off: geen WLAN-standaard encryptietechniek toegepast, maar andere encryptie zoals Ipsec voor een VPN kan wel aanwezig zijn. Daarnaast wordt proprietary encryptie (is door leverancier ontwikkelde, maar niet gestandaardiseerde encryptie) niet gedetecteerd. • Encryption on: WLAN-encryptie wordt gebruikt. • ESS (access point): het WLAN device werkt in Extended Service Set mode en is dus een access point. • IBSS (peer): het WLAN device werkt in Independent Basic Service Set mode en is dus in peer mode (is recht-

streekse communicatie tussen WLAN devices zonder tussenkomst van een access point). • CF Pollable: contention free pollable is een andere techniek waarbij ieder device op vaste intervallen mag gaan zenden. • Short Preamble: een verkorte header van de pakketten voor een hogere verbindingssnelheid. • PBCC: packet binary convolutional code is een techniek waardoor hogere verbindingssnelheden kunnen worden gehaald. • Short Slot Time (11g): turnaround tijd van berichten wordt verkort waardoor een hogere verbindingssnelheid kan worden gehaald. • Default SSID: een standaard SSID wordt gebruikt voor de naam van het WLAN-netwerk. Wanneer WLAN-netwerken een default SSID en geen encryptie hebben, dan zijn dit netwerken waarbij het opzetten van een verbinding een grotere kans van slagen heeft. Netstumbler en GPS Het is mogelijk om met netstumbler een Global Positioning Systeem (GPS) apparaat te gebruiken. Hierdoor wordt naast de eigenschappen en signaalsterkte van een WLAN device eveneens de GPS-positie opgeslagen waar het signaal is opgevangen. De signaalsterkte en de GPS-positie zijn te gebruiken voor het uitrekenen van de positie van een WLAN device. Deze berekenwijze heet triangulatie en bestaat uit het berekenen van het snijpunt van drie cirkels (zie figuur 3). Door het gebruik van GPS met Netstumbler is het mogelijk hele gebieden in kaart te brengen inclusief de exacte locatie van access points.

Figuur 3. Triangulatie Passieve scanning Naast actieve scanning waarbij access points worden benaderd om zichzelf bekend te maken, is het ook moge-


lijk om al het WLAN-netwerkverkeer op te vangen (sniffing). De opgeslagen gegevens kunnen dan meteen dan wel later worden onderzocht om te achterhalen of een access point aanwezig is en welke eigenschappen het WLAN-netwerk heeft.

Intrusion Detection System (Wireless IDS), omdat bij het detecteren van bepaalde netwerkpakketten wellicht een intrusion gaande is en bepaalde acties kunnen worden ondernomen. Zo kan Kismet bijvoorbeeld de ‘ping’berichten van Netstumbler herkennen.

Kismet

Ethereal

Naam

Kismet

Naam

Ethereal

Soort

Gratis

Soort

Gratis

Platform

Linux/Windows

Platform

Linux/Windows

Website

http://www.kismetwireless.net

Website

http://www.ethereal.com

Doel

Sniffen van wireless netwerkverkeer

Doel

Sniffen van (wireless) netwerkverkeer

Voor het passief scannen kan de IT-auditor gebruikmaken van Kismet. Kismet is een veelzijdig Linux-programma dat overigens ook in een Windows-omgeving werkend te krijgen is. Het stelt de IT-auditor onder andere in staat ook de ‘verborgen’ WLAN devices in kaart te brengen. Kismet kan al het WLAN-netwerkverkeer opvangen en vervolgens de netwerkpakketten analyseren. Op basis van de analyse wordt een access point herkend en de daaraan gekoppelde clients (zie figuur 4). Verder worden de opgevangen netwerkpakketten gecategoriseerd in managementpakketten en gegevenspakketten. Met name de managementpakketten bevatten waardevolle informatie voor nadere analyse. Deze managementpakketten zijn op te slaan in een bestandsformaat dat kan worden gelezen door ethereal, zodat de pakketten inhoudelijk kunnen worden onderzocht. Kismet kan ook in combinatie met een GPS worden gebruikt.

Voor het sniffen van netwerkverkeer inclusief WLAN-netwerkverkeer kan ethereal worden gebruikt. Bij de hiervoor beschreven tools gaat het met name om de headers van de netwerkpakketten, maar ethereal maakt het ook mogelijk inhoudelijk de netwerkpakketten te onderzoeken. Daarnaast kunnen netwerksessies worden gevolgd door deze aan te klikken en te kiezen voor het volgen van de sessie.

Figuur 5. De Ethereal sniffer Ethereal heeft voor WLAN-kaarten een speciale optie om alleen interessante netwerkpakketten te filteren. Hierdoor is het mogelijk om specifiek die pakketten te achterhalen die gebruikt worden voor authenticatie, key exchange of andere beveiligingsgerelateerde gebeurtenissen. Figuur 4. Kismet-gegevens van acces point Kismet als IDS Met Kismet is het ook mogelijk om real-time (bijzondere) WLAN-pakketten te onderscheppen. De onderschepte berichten kunnen vervolgens worden onderzocht op inhoud waarna actie kan worden ondernomen. Hierdoor is Kismet tevens te gebruiken als (beperkte) Wireless

Airopeek Naam

Airopeek

Soort

Commercieel

Platform

Windows

Website

http://www.wildpackets.com

Doel

Scannen en sniffen van wireless netwerkverkeer

23

24


Airopeek is een commerciële tool waarin allerlei losse tools die hiervoor zijn beschreven zijn geïntegreerd. Zo is airopeek in staat om zowel actief op zoek te gaan naar access points, maar kan daarnaast het netwerkverkeer sniffen en kan bovendien de opgevangen gegevens nader onderzoeken. Airopeek heeft naast de mogelijkheden van de hiervoor beschreven tools bijvoorbeeld de mogelijkheid om communicatie tussen WLAN devices te visualiseren. Hierdoor wordt inzichtelijk welke WLAN device contact heeft met welke andere WLAN devices en hoeveel netwerkverkeer hiertussen wordt uitgewisseld (zie figuur 6).

diverse beveiligingstechnieken toegepast. De meest bekende hiervan zijn WEP (Wired Equivalent Privacy), WPA (Wireless Protected Access) en LEAP (Lightweight Extensible and Authentication Protocol). Voor deze beveiligingstechnieken zijn al geruime tijd tools voor de aanval beschikbaar. Verwacht wordt dat deze tools in de toekomst nog verder ontwikkeld zullen worden, waardoor ze effectiever en efficiënter zullen zijn in het gebruik. In deze paragraaf zal kort worden ingegaan op de tools ten behoeve van het aanvallen van de genoemde protocollen. WEP Het aanvallen van WEP kan op verschillende wijzen worden uitgevoerd. De belangrijkste typen aanvallen zijn te verdelen in: • brute force/dictionary aanvallen; • Fluhrer-Mantin-Shamir (FMS)-aanval; • packet injection aanvallen. Brute force/dictionary aanvallen

Figuur 6. Airopeek in actie

Exploiting Na de reconnaissance is het WLAN-netwerk geïdentificeerd en zijn de belangrijkste beveiligingseigenschappen bekend zoals het gebruikte protocol, SSID, encryptie, et cetera. In de exploiting fase is het de bedoeling om daadwerkelijk toegang te krijgen tot het betreffende WLANnetwerk, zodat hierna achterliggende netwerken en aanwezige systemen kunnen worden benaderd. De in de exploiting fase gebruikte tools kunnen worden verdeeld in de volgende categorieën: • tools ten behoeve van het kraken van beveiligingsprotocollen; • wireless client hijackers; • 802.11 protocol attack tools. Tools ten behoeve van het kraken van beveiligingsprotocollen Binnen de WLAN-toepassingen van dit moment worden

Naam

Wepattack

Soort

Gratis

Platform

Linux/cygwin

Website

http://www.sourceforge.net/projects/wepattack

Doel

Kraken van encryptie (dictionary attack)

De brute force-aanval is de meest eenvoudige aanval. Hiervoor is slechts één WEP versleuteld pakketje nodig waarop vervolgens, al dan niet gedistribueerd, een brute force-aanval wordt uitgevoerd. Met behulp van één van de eerder genoemde reconnaissance tools kan men eenvoudig pakketjes opvangen (‘sniffen’). Vervolgens kan men met behulp van de tool wepattack een ‘dictionary attack’ uitvoeren. Een dergelijke dictionary attack is afhankelijk van de grootte van de gebruikte dictionary, maar over het algemeen duurt zo’n aanval enkele seconden en kan snel worden bepaald of het netwerk kwetsbaar is of niet. FMS aanval In de zomer van 2001 werd bekend dat WEP kwetsbaar is voor een zogenaamde ‘mathematical attack’. Dit type aanval werd bekend als de Fluhrer-Mantin-Shamir (FMS) aanval. Deze aanval, ontdekt door de wiskundigen Fluhrer, Mantin en Shamir, maakt misbruik van een zwakte in de gebruikte versleutelingsmethode van WEP. Uit het onderzoek van Fluhrer, Mantin en Shamir blijkt namelijk dat bij het gebruik van WEP een klein percentage ‘zwakke’ pakketjes worden gegenereerd, die een deel van de WEP-sleutel in zwak versleutelde vorm kan bevatten. Enkele ‘proof-of-concept’ tools volgden snel.


device de ether instuurt, te vergroten. Hierdoor wordt op actieve wijze het WLAN-netwerk beïnvloed en dit kan verstorend werken op het WLAN-netwerk en leiden tot integriteits- en continuïteitsproblemen. Het is aan te raden zeer voorzichtig met packet injection tools om te gaan. WPA

Figuur 7. Airsnort al krakende een WEP-sleutel Naam

Airsnort

Soort

Gratis

Platform

Linux

Website

http://www.airsnort.shmoo.org

Doel

Kraken WEP encryptie (FMS aanval)

De meest bekende tool die gebruikmaakt van de FMSaanval is ‘airsnort’. In het kort komt het erop neer dat met behulp van deze tool ‘zwakke’ pakketjes worden verzameld en indien voldoende van deze pakketjes verzameld zijn, dan is het mogelijk om de originele WEP-sleutel hieruit te extraheren. Een nadeel bij deze tool is dat de aanvaller moet wachten totdat voldoende ‘zwakke’ pakketjes zijn verzameld. Dit kan afhankelijk van de drukte van het WLAN-netwerk enkele uren tot meerdere maanden duren. In een aantal gevallen zal zelfs een beperkt aantal zwakke pakketjes worden gegenereerd en is de wachttijd oneindig lang. De fabrikant Agere heeft zelfs een verbeterde versie van WEP uitgebracht, genaamd WEPplus, waarbij vrijwel geen zwakke pakketjes voorkomen en een FMS-aanval dus niet effectief is. Packet injection aanvallen Naam

Aircrack

Soort

Gratis

Platform

Linux/cygwin

Website

http://www.cr0.net:8040/code/network

Doel

Kraken WEP encryptie (packet injection)

De eerder genoemde aanvallen maken gebruik van passieve methoden en hebben geen invloed op het WLAN-verkeer. Bij packet injections tools is dat heel anders. Met de tool ‘aireplay’ (onderdeel van aircrack) worden speciaal gevormde WLAN-pakketjes de ether ingestuurd met het doel om het aantal ‘zwakke’ pakketjes dat een WLAN

Naam

WPA cracker

Soort

Gratis

Platform

Linux/cygwin

Website

http://www.tinypeap.com/html/wpa_cracker.html

Doel

Kraken WPA-PSK encryptie

WPA staat bekend als de opvolger van WEP. Bij WPA wordt gebruikgemaakt van meer betrouwbare vormen van encryptie. WPA bevat echter niet alleen voorzieningen voor versleuteling van data, maar bijvoorbeeld ook voorzieningen ten behoeve van authenticatie en integriteitscontrole van pakketten. Van WPA bestaan meerdere varianten, die zijn te groeperen in twee groepen: • enterprise mode: protocol met onder andere ‘per-user’ authenticatie en speciale voorzieningen voor key management en integriteitscontrole; • consumer mode: ‘pre-shared’ key based protocol op basis van verschillende technieken van encryptie zoals TKIP en AES (‘consumentenversie’ ook wel aangeduid als WPA-PSK). De ‘consumentenversie’ van WPA in combinatie met TKIP-encryptie (Temporal Key Integrity Protocol) is een tijdje geleden gekraakt. Een handige tool voor het kraken van WPA-PSK is ‘WPA cracker’. WPA cracker kan de pre-shared key aanvallen door middel van een off-linewoordenboekaanval. Hierbij wordt getest of de sleutel voor het WPA-PSK-netwerk in het woordenboek voorkomt. Wanneer de sleutel wordt aangetroffen kan een verbinding met het WLAN-netwerk worden gemaakt. Indien gebruik wordt gemaakt van een complexe pre-shared key met een lengte van meer dan 20 karakters, dan zal deze aanval echter niet succesvol kunnen zijn. Tevens kan deze tool niet gebruikt worden om netwerken met ‘enterprise mode WPA’ of WPA-PSK met AES encryptie (Advanced Encryption Standard) aan te vallen. LEAP Het Lightweight Extensible and Authentication Protocol (LEAP) is een Cisco-specifiek beveiligingsprotocol, dat gebruikmaakt van authenticatie op basis van username/ password in combinatie met een RADIUS-server en encryptie (bijvoorbeeld WEP).

25

26


Naam

Asleap

Soort

Gratis

Platform

Linux/cygwin

Website

http://www.asleap.sourceforge.net

Doel

Kraken LEAP

• zich voordoen als ieder gewenst access point voor iedere client; • aanvallen van het werkstation; • aanvallen van de netwerkverkeersstromen vanuit het werkstation richting andere systemen. 802.11 protocol attack tools

In augustus 2003 heeft Joshua Wright de tool ‘asleap’ geschreven waarmee men in staat is zwakke username/ password-combinaties te achterhalen op basis van een offline dictionary attack. Indien gebruik wordt gemaakt van complexe username en password-combinaties zal een aanval met behulp van deze tool echter niet succesvol zijn. Een bijkomend voordeel van deze tool is, dat het ook kan worden gebruikt voor een aanval op het PPTP-protocol. Het PPTP-protocol wordt vaak voor VPN-verbindingen gebruikt.

Naam

Void 11

Soort

Gratis

Platform

Linux/cygwin

Website

http://www.wlsec.net/void11/

Doel

Protocol gerichte aanval

De auditor kan in bepaalde gevallen gebruikmaken van 802.11 protocol attack tools voor het misbruiken van kwetsbaarheden in het protocol. Veelal zijn deze tools gericht op het uitvoeren van een denial-of-service aanval. Een goed voorbeeld hiervan is void11. Met void11 is een aanvaller in staat om zowel een netwerk aanval als een access point aanval te starten. Bij de eerste variant wordt het wireless netwerk overspoeld met nep ‘deauthentication’ pakketjes, waardoor actieve verbindingen worden verbroken. Bij de tweede variant wordt een access point overspoeld met nep ‘authentication’ pakketjes, waardoor het access point buiten werking kan raken en in sommige gevallen zelfs (fysiek) defect kan raken.

Figuur 8. Asleap in actie

Conclusie Wireless client hijackers Naam

KARMA

Soort

Gratis

Platform

Linux/cygwin

Website

http://theta44.org/karma/index.html

Doel

Wireless client hijacker

Een wireless client hijacker is een tool dat kan worden gebruikt om wireless clients (bijvoorbeeld werkstations) een verbinding te laten opzetten met een nep access point. Hiermee wordt het mogelijk om bestaande verbindingen te verbreken en vervolgens het wireless werkstation een verbinding te laten opzetten met het access point van de aanvaller. Op deze manier kan een aanvaller een vervolgaanval inzetten op het betreffende werkstation en/of de verbindingen van het werkstation door het nep access point heen. De ‘KARMA Wireless Client assessment tool’ is hiervoor zeer bruikbaar, omdat deze tool ingebouwde mogelijkheden heeft voor het: • verbreken van de verbinding van een werkstation;

Voor het testen van de beveiliging van WLAN-netwerken kan gebruik worden gemaakt van een groeiende lijst van tools. Wanneer systematisch WLAN-netwerken worden verkend (reconnaissance) en vervolgens worden aangevallen (exploiting), kunnen slecht beveiligde WLAN-netwerken eenvoudig worden gekraakt. Voor het kraken van de beter beveiligde WLAN-netwerken is meer tijd nodig en zijn minder tools beschikbaar. In een aantal gevallen zijn deze netwerken momenteel zelfs helemaal niet te kraken. In de toekomst zal echter het aantal tools en de kwaliteit ervan verbeteren, waardoor deze netwerken mogelijk ook te kraken zijn. Naast het direct aanvallen van WLAN-netwerken en wireless devices, bestaan ook andere typen aanvallen. Deze aanvallen zijn steeds meer in opspraak zoals in het geval van Warlounging, Evil-twin-aanvallen en Inverse wardriving (zie kader). Deze aanvallen hebben niet direct te maken met het aanvallen van access points, maar meer met het steeds meer beschikbaar komen van (open) WLAN-netwerken en het toenemende gebruik hiervan. De


risico’s die in dit verlengde liggen, hebben voornamelijk betrekking op wireless clients zoals PDA’s en laptops.

‘Evil twin’-aanval Een ‘evil twin’-aanval is een aanval gebaseerd op het aan-

Misschien zijn WLAN-netwerken zelf nooit veilig te krijgen en kan alleen een sterke VPN-oplossing over WLAN voldoende zijn of wordt de standaard WLAN-beveiliging toch uiteindelijk voldoende. In een volgend artikel zal worden ingegaan op de maatregelen voor WLAN-beveiliging waarin wordt beschrijven welke maatregelen genomen dienen te worden om een veilig WLAN te krijgen/hebben.

bieden van een ogenschijnlijk betrouwbaar acces point, vergelijkbaar met een wireless client hijack. Veel mensen die gebruikmaken van gratis of betaalde publieke hotspots hebben te maken met het feit dat zij het access point moeten selecteren voordat de verbinding wordt opgezet. Vaak wordt het access point vertrouwd op basis van de naam van het access point. In figuur 2 is een lijst te zien met aanwezige access points in een hotel (‘eurospot’). De meeste gebruikers zullen blindelings een van deze access points selecteren en zullen zich niet realiseren dat het mogelijk is

Warlounging

dat een hacker een of meerdere van deze access points zelf

Warlounging is een relatief onbekend fenomeen en heeft

heeft geplaatst met dezelfde naam. Een hacker kan vervol-

weinig te maken met ‘lounging’. Het is de aanduiding voor

gens alle communicatie omleiden over zijn eigen infrastruc-

een nieuwe vorm van worm-aanvallen: de zogenaamde

tuur en vervolgens doorsluizen naar het internet. De

Wi-Fi wormen. Bij een dergelijke aanval wordt een wireless

gebruiker van het access point zal hier weinig van merken,

client device omgetoverd tot een access point, zonder dat

terwijl de hacker in staat is diverse man-in-the-middle aan-

de gebruiker dit merkt. Dit risico doet zich met name voor

vallen uit te voeren op VPN, SSL, SSH en diverse andere

bij laptops en pc’s die standaard voorzien zijn van een

protocollen. ‘Evil twin’-aanvallen zijn werkelijkheid: in

wirelesskaart en een netwerkkaart. Indien het werkstation

Londen zijn tijdens een congres (over WLAN notabene)

besmet wordt met een Wi-Fi worm, is het mogelijk dat deze

tientallen werkstations gehacked met een dergelijke aanval.

Wi-Fi worm de (vanuit beveiligingsoogpunt) gedeactiveerde wirelesskaart activeert en hierop een access point installeert. De worm stuurt vervolgens locatiegegevens (op basis van IP-nummer) door naar de aanvaller op het internet.

‘Inverse wardriving’

De aanvaller kan vervolgens een verbinding opzetten

‘Inverse wardriving’ is de omgekeerde wereld. Iedereen

met het werkstation. Indien gebruik wordt gemaakt van

kent wel het fenomeen van wardriving, waarbij een wardri-

Windows XP, kan de aanvaller in bepaalde situaties via het

ver op zoek gaat naar access points met behulp van een

werkstation een connectie maken met het achterliggende

wireless client. Bij ‘inverse wardriving’ is dit andersom: een

(bedrijfs)netwerk. Deze aanval is bekend als de Windows

inverse wardriver gaat met een access point op zoek naar

XP Virtual bridging aanval. Warlounging is geen science fic-

wireless clients. Gezien het feit dat er veel meer wireless

tion, proof-of-concept code is reeds op het internet te

clients zijn dan wireless access points, zal de kans van een

downloaden. Deze code is ook beschikbaar voor schrijvers

succesvolle aanval met behulp van inverse wardriving een

van wormvirussen.

veelvoud groter zijn ten opzichte van wardriving.

27

28


Ketenauditing in de publieke sector, complex en daarom spannend! In het bedrijfsleven is samenwerken in ketenverband een wat ouder verschijnsel, noodzakelijk voor het beter bedienen van de klant of om de concurrentie de baas te blijven. Binnen de overheid is ketensamenwerking een nieuw fenomeen en vindt veelal niet plaats op vrijwillige basis maar Anastasia van der Meer en Leon Dirks

wordt meestal om politieke redenen opgelegd.

Over ketens en ketenmanagement in het bedrijfsleven bestaat veel literatuur, maar over ketens binnen de overheid en de beheersing daarvan is nog weinig gepubliceerd. Bij interdepartementale samenwerking is niet één minister, maar zijn verschillende ministers eindverantwoordelijk voor een bepaald overheidsproces en overheidsdienst. Hierdoor ontstaan aansturings- en uitvoeringsconstructies, die qua beheersing complex zijn. Wat komt er precies kijken bij deze complexe beheersing en wie heeft welke verantwoordelijkheden. Is een ketenaudit daarvoor een adequaat meetinstrument? Wat onderscheidt een ketenaudit van een reguliere audit en welke deskundigheden zijn 1 daarbij vereist? Dit artikel gaat in op deze vragen .

en gemeenten. Verder stimuleert het kabinet de onderlinge samenwerking tussen departementen en agentschappen. Eén van de meest recente ontwikkelingen op dit gebied is de samenwerking tussen de ministeries van Financiën en van Volkshuisvesting Ruimtelijke Ordening en Milieubeheer (VROM) bij de uitvoering van de huursubsidie. Binnen het bedrijfsleven is ketenvorming al een wat ouder verschijnsel. Bedrijven zijn genoodzaakt om samen te werken voor het optimaal bedienen van de klant dan wel om de concurrentie het hoofd te bieden. Een voorbeeld hiervan is de samenwerking in de agrarische sector waarbij een product via een zo kort mogelijke doorlooptijd vers de klant moet bereiken.

Inleiding

Algemeen kan worden gesteld dat ketensamenwerking is ontstaan omdat een fusie van organisaties in de praktijk vaak niet blijkt te voldoen. Een reden hiervoor is dat organisatiestructuren en culturen niet eenvoudig op elkaar zijn af te stemmen. In geval van een ketensamenwerking blijven de partijen zelfstandig en wordt alleen samengewerkt waar sprake is van raakvlakken en toegevoegde waarde. Over ketenmanagement bestaat weliswaar veel literatuur, maar er is nog weinig geschreven over ketens binnen de overheid en de beheersing daarvan. Dit onderscheid tussen ketens binnen de overheid en het bedrijfsleven is essentieel. De ketensamenwerking binnen het bedrijfsleven is vooral een vrijwillige, vraaggerichte keuze van de betrokkenen. Bij de overheid is vaak sprake van ketensamenwerking die van bovenaf/centraal is opgelegd.

Steeds vaker roept de overheid op tot samenwerking tussen overheidsdiensten. Dit gebeurt op verschillende niveaus. Bijvoorbeeld in de waterketen zien we samenwerkingsverbanden ontstaan tussen rijksoverheid, provincies

Drs. A.J. van der Meer is werkzaam in de sector Onderzoek en Marketing van het Belastingdienst Centrum voor Proces en Productontwikkeling. Daarvoor was zij ruim 7 jaar auditmedewerker bij de Interne Accountantsdienst Belastingen (tegenwoordig Auditdienst Financiën). Drs. L.G. Dirks is werkzaam bij de Auditdienst van het ministerie van VROM als IT-auditor. Daarvoor was hij ruim 4 jaar IT-auditor bij EDP AUDIT POOL, directie van het ministerie van Financiën. De auteurs hebben dit artikel geschreven op persoonlijke titel.

Bij de keuze voor interdepartementale samenwerking ontstaat een ketenproces van volgtijdelijke activiteiten die


over meerdere departementen heenlopen. Niet langer één, maar meer ministers zijn eindverantwoordelijk voor een overheidsproces. Hierdoor ontstaan ingewikkelde aansturings- en uitvoeringsconstructies. Dit heeft tevens gevolgen voor de beheersing en het toezicht op deze interdepartementale ketenprocessen. Deze ontwikkelingen geven binnen de overheid aanleiding tot het uitvoeren van ketenaudits, maar wat is eigenlijk een ketenaudit en welke rol en verantwoordelijkheden zijn weggelegd voor de overheidsauditdiensten die zulke ketenaudits gaan uitvoeren? Welke deskundigheid vereist het uitvoeren van een ketenaudit? Mede op dit soort vragen was binnen de overheid behoefte aan een antwoord. Daarom heeft een aantal medewerkers, afkomstig van verschillende auditdiensten, een inventariserend onderzoek uitgevoerd. Dit heeft geleid tot het rapport ‘Ketenauditing, nieuw en daarom spannend’ [FIN04]. In dit artikel vatten we het rapport samen. Genoemd rapport heeft inmiddels op verschillende manieren follow-up gekregen. Zo heeft het Instituut voor de Nederlandse Kwaliteit (INK) de inhoud van het rapport gebruikt voor het ontwikkelen van een kwaliteitsbeheersingsmodel voor een keten. De Auditdienst Financiën heeft de ontwikkelde ‘best practices voor de ketenauditor’ toegepast op diverse strategische projecten. Ook is de gedachtevorming rond ketenauditing verder ontwikkeld door een werkgroep die de Nederlandse Organisatie voor Register EDP Auditors (NOREA) heeft ingesteld. Deze werkgroep bestaat uit vertegenwoordigers van de Auditdienst Financiën, PricewaterhouseCoopers (PWC) en Uitvoering Werknemers Verzekeringen (UWV). In een tweede artikel over Ketenauditing zullen de producten van deze laatste werkgroep worden toegelicht. Dit eerste artikel vormt daarvoor de opstap. De kennis over ketenaudit in het algemeen die wij in dit artikel samenvatten vormt een opstap naar de verbijzondering of specifieke toepassingsvormen zoals een ketenaudit op een stelsel van IT-systemen. Vooruitlopend zullen wij in dit artikel aandacht besteden aan literatuur en studies op het terrein van IT-ketenauditing. Leeswijzer In de volgende paragraaf behandelen wij diverse begrippen die te maken hebben met ketens, ketenmanagement en ketenauditing. Dan volgt een paragraaf dat beschrijft vanuit welke invalshoeken de behoeften aan ketenauditing zijn onderzocht. Vervolgens gaan we in op het onderscheid tussen informatieketen en keteninformatisering en theorieën van Grijpink op dit terrein. Daarna behandelen we de opzet van een ketenaudit. Dit gebeurt enerzijds van-

uit het onderzoeksproces en anderzijds vanuit het onderzoeksobject. In de daaropvolgende paragraaf staat een overzicht van best practices die bij de uitvoering van een ketenaudit van pas kunnen komen. Vervolgens sluiten wij dit artikel af met een aantal eindconclusies.

Begrippen rondom keten en ketenaudit In de literatuur wordt een keten als volgt omschreven [BZK04]: Een keten is een samenwerkingsverband tussen partijen die zowel zelfstandig als afhankelijk van elkaar functioneren omdat ze volgtijdelijke handelingen uitvoeren gericht op een afzonderlijk doel. Bij de ordening en afstemming van activiteiten houden de partijen het oog op de bal: de cliënt die het ‘primaire proces’ doorloopt, de opeenvolgende stappen in de dienstverlening. Tijdens ons onderzoek hebben wij de volgende definitie gehanteerd: Een keten is een samenwerkingsverband tussen verschillende overheidsorganisaties voor de uitvoering van een proces waarbij meerdere departementen betrokken zijn. De eindverantwoordelijkheid voor de uitvoering ervan kan bij één departement of bij verschillende departementen liggen. Het begrip netwerk wordt vaak als synoniem gehanteerd voor het begrip keten, maar dit is niet hetzelfde. Een netwerk definiëren we als een verzameling van relaties met een gemeenschappelijk belang: weten van elkaars aanwezigheid en die eventueel benutten. Een netwerk kan leiden tot een keten als partijen elkaar weten te vinden en van elkaar gebruik gaan maken. Bij een keten is evenwel sprake van een proces; bij een netwerk niet. Schakels De stappen in het ketenproces worden ook wel aangeduid met de term schakels. Binnen één organisatie kunnen meerdere schakels worden uitgevoerd. De invloed die een ketenpartner heeft op de keten als geheel hangt allereerst af van het aantal schakels dat wordt ingebracht. Daarnaast is het van belang welk type schakels een ketenpartner inbrengt: zwakke, smalle, divergerende of selecterende schakels. Eén zwakke schakel kan het hele ketenproces verstoren. Een smalle schakel lijkt vanwege de geringe omvang (keteninbreng) onbeduidend, maar kan als dwarsligger macht uitoefenen op de gehele keten. Divergerende en selecterende schakels zijn bepalend voor de procesgang in de keten. Binnen selecterende schakels worden keuzes gedaan die conditionerend zijn voor de manier waarop de ‘bal’ verder rolt door het ketenproces.

29

30


Binnen divergerende schakels vindt in het ketenproces de algemene voorbereiding plaats, waarna divergeren (uitwaaieren in verschillende richtingen) volgt. De bovenstaande typologie van schakels kan worden gebruikt als instrument om de strategische positie van de keten als geheel vast te stellen. Dat kan bijvoorbeeld van pas komen tijdens de keuze van de ketenpartners en bij de beheersing van het ketenproces. De sterkte (strategische positie) van de keten hangt verder nog in belangrijke mate af van de koppelpunten (interfaces) tussen de schakels. Koppeling kan op verschillende manieren vorm krijgen, bijvoorbeeld via het afstemmen van procesinrichting, uitwisseling van gegevens via gemeenschappelijke/gekoppelde informatiesystemen, gezamenlijke uitvoering van taken en overleg. Vooral wanneer de breukvlakken in de keten samenvallen met de juridische en bestuurlijke (organisatie)grenzen, dient bij de beheersing van de keten meer aandacht te bestaan voor de wijze waarop de schakels worden verbonden. Typen ketens In de literatuur worden verschillende typen ketens onderscheiden: • dynamische ketens; • vraag- en aanbodgerichte ketens; • beleidsketens; • fysieke ketens; • complexe en eenvoudige ketens; • verticale, horizontale en diagonale ketens. Deze worden hierna kort behandeld. Dynamische ketens Een keten hoeft niet per se een duurzaam samenwerkingsverband te zijn. Het kan erop zijn gericht om een tijdelijk probleem op te lossen. Ook is het mogelijk dat een keten in de loop der tijd van samenstelling verandert. In de literatuur bestaat een opvatting dat een keten per definitie dynamisch is [GRIJP02]. Volgens deze opvatting ontstaat een keten rondom een dominant probleem. Dit kan in de loop der tijd een andere inhoud krijgen waardoor ook de ketensamenstelling kan veranderen. Er zal daarom voortdurend sprake zijn van ketenherontwerp. Vraag- en aanbodgerichte ketens Hoe groter de invloed van de klant, des te meer behoefte zullen zelfstandige organisaties (producenten en distributeurs) krijgen om bij elkaar steun te zoeken. Het in een zo kort mogelijke tijd leveren van de beste kwaliteit aan de klant noopt tot samenwerking. Er is in dit geval sprake van vraaggerichte ketens.

Daartegenover staan aanbodgerichte ketens. Daarbij is in de meeste gevallen sprake van gedwongen samenwerking. De politiek legt in zulke gevallen samenwerking op aan publieke lichamen. Doel is het oplossen van een dominant probleem dan wel het wegnemen van een bepaald maatschappelijk risico. Beleidsketens Bij een beleidsketen is er sprake van interdepartementale samenwerking op één gemeenschappelijk beleidsveld. Een beleidsketen onderscheidt zich op de volgende punten van een fysieke keten: • Bij een beleidsketen is weliswaar sprake van een proces met als doel het maken van beleid, maar dit is minder tastbaar dan het proces binnen een fysieke keten. • Binnen een beleidsketen spelen zich bestuurlijke processen af via bijvoorbeeld interdepartementaal overleg. Dat lijkt meer op afstemming dan op samenwerking. • De beleidsketen (landelijk bestuursniveau) staat vaak boven de fysieke keten. De ruimte die de fysieke keten krijgt, zal afhangen van de ruimte die de beleidskaders bieden. Fysieke ketens De ketensamenwerking kan gericht zijn op een fysiek (tastbaar) bedrijfsvoeringproces met een duidelijke invoer, doorvoer en uitvoer. In dat geval wordt gesproken van een fysieke keten. Net als in een zelfstandige organisatie bestaat (in een fysieke keten als geheel) een operationeel, een tactisch en een strategisch managementniveau. Bij fysieke ketens kan op een operationeel niveau sprake zijn van: • Logistieke ketens: In de agro-keten wordt samengewerkt om de doorlooptijd te verkorten; het voedsel kan dan zo vers mogelijk de klant bereiken. • Economische ketens: Industriële ondernemingen werken samen om kosten te besparen, concurrentie te verminderen en de consumentenprijs zo laag mogelijk te houden. • Informatiseringketens: In de strafrechtketen wisselen politie en het ministerie van Justitie met elkaar gegevens uit. Complexe en eenvoudige ketens In de literatuur wordt onderscheid gemaakt tussen eenvoudige en complexe ketens [BZK04]: • Eenvoudige ketens zijn aanbodgericht. De samenwerking is min of meer opgelegd en komt niet voort uit een overlevingsstrategie. De reden hiervoor is dat de ketenpartners monopolisten zijn met een hoge machtsconcentratie. Het ketendoel wijzigt nauwelijks in de loop der tijd omdat er sprake is van een stabiele omgeving. De verdeling van taken, verantwoordelijkheden en bevoegd-


heden is transparant (vaak hiërarchisch belegd). Door de stabiliteit van de omgeving en het ketendoel is er weinig noodzaak om de ketensamenstelling te veranderen. Een voorbeeld is de defensieketen (samenwerking tussen marine, luchtmacht en landmacht). Door de eenvoud en stabiliteit van dit type ketens is de ketenbesturing en -beheersing makkelijker te organiseren en uit te voeren. • Complexe ketens zijn vraaggericht. In complexe ketens is samenwerking tussen de betrokken bedrijven noodzakelijk om geen klanten te verliezen. De omgeving, het ketendoel en de ketensamenstelling hangen met elkaar samen en zijn voortdurend in beweging. Relaties en verantwoordelijkheden zijn complex. Zulke ketens gaan richting netwerk. Het dynamische en complexe karakter van deze ketens bemoeilijkt de aansturing, het toezicht en de beheersing ervan. Een voorbeeld is aanpak van de drugsproblematiek door de ministeries van Volksgezondheid Wetenschap en Sport (VWS), Binnenlandse Zaken (BZK) en Justitie. Verticale, horizontale en diagonale ketens De indeling naar verticaal, horizontaal en diagonaal heeft betrekking op zowel de aansturing als op het proces van de keten. Qua aansturing is er sprake van een verticale keten als er één centrale eindverantwoordelijke is voor een keten die door opeenvolgende bestuurslagen heen loopt. Een voorbeeld hiervan is een ketenproces dat zich afspeelt binnen één departement waarvoor de minister de eindverantwoordelijke is. Een horizontale keten daarentegen is een samenwerkingsverband waarbij niet één maar meer eindverantwoordelijken binnen één bestuurslaag zijn aan te wijzen. Bij een interdepartementale samenwerking bijvoorbeeld is de eindverantwoordelijkheid verdeeld over verschillende ministers. Enkele voorbeelden van interdepartementale ketens zijn de strafrechtketen (samenwerking tussen politie, openbaar ministerie, rechterlijke macht, gevangenissen, reclassering, et cetera), de veiligheidsketen (samenwerking tussen de departementen BZK, VROM, ministerie van Justitie) en de huursubsidieketen (het beleid is afkomstig van VROM, de uitvoering wordt binnenkort overgedragen aan de Belastingdienst). Qua ketenproces is ook een indeling te maken naar horizontaal en verticaal. Zoals eerder al is opgemerkt kan een ketenproces bestaan uit opeenvolgende fasen (verticaal); een voorbeeld hiervan is de agro-keten (van zaad tot vers). Een ketenproces kan evenwel ook bestaan uit parallelle fasen (horizontaal); een voorbeeld daarvan is de operatie van een patiënt waarbij verschillende soorten specialisten en verpleegkundigen tegelijkertijd met elkaar samenwerken.

Een diagonale keten is in bestuurlijk en procesmatig opzicht een combinatie van een horizontale en verticale keten: het is bijvoorbeeld een keten die door verschillende departementen en bestuurslagen heen loopt. Een voorbeeld is de waterketen. Betrokken departementen zijn VROM en Verkeer & Waterstaat (V&W). De bestuurslagen zijn de gemeenten, de provincies en het rijk. De uitvoerenden zijn de waterschappen en de drinkwaterbedrijven. Figuur 1 (zie pag. 32) verduidelijkt de begrippen horizontale en verticale ketens. Ketenbetrokkenen Bij een keten gelden als betrokkenen: samenwerkingspartners, kennispartners, opdrachtgevers, financiers, regisseurs, toezichthouders, afnemers en belangengroeperingen. Vaak zijn er vooraf geen duidelijke afspraken gemaakt over wie binnen en/of buiten de keten welke taken, verantwoordelijkheden en bevoegdheden op zich neemt ten aanzien van bijvoorbeeld initiatief, inrichting, regie, toezicht, beheersing en financiering. Daarom kunnen deze aangelegenheden in de praktijk diffuus verlopen of zelfs geheel ontbreken. Het gevolg is gewoonlijk dat ketenpartners elkaar bij knelpunten de ‘zwarte piet’ toespelen omdat niemand eindverantwoordelijk is voor het geheel. Ook is binnen de keten sprake van machtsdistributie; doorgaans heeft niet elke partner evenveel macht. De hoeveelheid macht kan afhangen van: marktaandeel, dominantie in de toegevoegde waarde aan de keten, aandeel in de financiering, positie in de wetgeving et cetera. Ketenaudit Op grond van het bovenstaande en de algemene definitie van een audit (Rijksacademie voor Financiën en Economie en het IODAD handboek) komen wij tot de volgende definitie voor een ketenaudit: Een ketenaudit is een onderzoek dat moet leiden tot een gefundeerd oordeel of advies over de beheersing van een keten als geheel ten aanzien van een gekozen object van onderzoek. De ketenaudit richt zich alleen op dát aspect of onderdeel van zelfstandige organisaties dat bijdraagt aan het gemeenschappelijke doel en de beheersing van de gehele keten. De resultaten worden gerapporteerd aan een duidelijke eigenaar/opdrachtgever. Gewoonlijk is dit de ketenregisseur die al of niet deel uitmaakt van de keten. Aan het einde van deze paragraaf kunnen we vaststellen dat, bij het hanteren van begrippen zoals keten, ketenschakels en ketenaudit, heldere definities zijn vereist. Het zijn veelomvattende begrippen die te kust en te keur worden gebruikt. Dat kan tot veel verwarring leiden en verhoogt

31

32


Bestuurstop

Bestuurstop

Bestuurstop

Ministerie I

Ministerie II

Ministerie III

Uitvoerende diensten



Ministerie I

Ministerie II

Ministerie III

Verticale

Horizontale keten

keten

Zelfstandige

Zelfstandige

Zelfstandige

Overheidsdiensten en



andere bestuursvormen



Provincies

Provincies

Provincies

Gemeenten

Gemeenten

Gemeenten

Figuur 1. Horizontale en verticale ketens de kans dat tijdens een ketenaudit de verkeerde zaken worden onderzocht. Anderzijds leveren de begrippen, die onder andere hierboven zijn uitgewerkt, analytische inzichten op voor de ketenauditor.

zichtorgaan verzorgd, bijvoorbeeld het Wetenschappelijk Onderzoeks en Documentatiecentrum (WODC) binnen het ministerie van Justitie en het Bureau Beleidsonderzoek (BBO) binnen het ministerie van Financiën.

Behoefte aan ketenauditing

• Departementale onderzoeken naar Government Governance Het instrument Government Governance legt de link tussen politieke besluitvorming, bestuur en bedrijfsvoeringverantwoording. Vanuit de visie van Government Governance heeft de directie Coördinatie Auditbeleid Departementen (CAD) van het ministerie van Financiën een handleiding ontwikkeld met vragenlijsten die departementen kunnen inzetten bij onderzoeken naar de governancestructuur [FIN00].

Tijdens het onderzoek werd duidelijk dat de behoefte aan ketenauditing kan ontstaan vanuit een vijftal invalshoeken. Deze zullen we achtereenvolgens noemen en beschrijven. Openbaar bestuur De overheid trekt zich terug als uitvoerder en toezichthouder maar schept nog wel de randvoorwaarden voor geprivatiseerde en verzelfstandigde organisaties om bepaalde overheidstaken te kunnen uitvoeren. Voorbeelden hiervan zijn de NS, de telecommarkt en recentelijk de energiemarkt. In dit kader zoeken partners elkaar op voor ketensamenwerking. De overheid is en blijft evenwel (vaak) eindverantwoordelijke. Hieruit is de behoefte ontstaan aan toezicht op het realiseren van beleidsdoelen, de effectieve en efficiënte inzet van middelen en de naleving van voorgeschreven kwaliteitsnormen. Deze vormen van toezicht zijn op de volgende manieren mogelijk: • Beleidsevaluaties door departementen Deze worden binnen elk departement vanuit een ander toe-

• Onderzoeken van de Algemene Rekenkamer (AR) De AR geldt als overkoepelend toezichtorgaan voor de gehele rijksoverheid. De AR heeft als voornaamste taak het uitvoeren van overkoepelend toezicht op de ministeries. Volgens geïnterviewden binnen de AR vallen ketens onder de ministeriële verantwoordelijkheid en niet onder die van de AR. Ook heeft de AR een rapport gepubliceerd [ALGE04], waarin wordt gepleit voor horizontalisering van de eindverantwoordelijkheid. Volgens dit rapport ligt de eindverantwoordelijkheid op een nog lager niveau dan ministerieel. Uitvoerenden, zoals verzelfstandigde en geprivatiseerde organisaties, dienen zelf de eindverant-


woordelijkheid te dragen voor de overheidstaken die aan hen zijn gedelegeerd. • Onderzoeken van de inspectiediensten De inspectiediensten houden toezicht op de naleving van de kwaliteitsnormen (bijvoorbeeld binnen het onderwijs en de gezondheidszorg). • (Keten)audits door de Departmentale Auditdiensten (DAD’s) Hierop komen we later in het artikel nog terug. Comptabiliteitswet De Comptabiliteitswet heeft op het punt van de ketenbenadering (ketenbeheersing) geen bepalingen. Dit is een witte vlek. In de wet heeft men de ministeriële verantwoordelijkheid als uitgangspunt gekozen en niet de ketenverantwoordelijkheid. Gezien het doel van de Comptabiliteitswet (transparantie richting de burger over de besteding van overheidsgeld) is de verwachting reëel dat de wet in de toekomst op dit punt zal worden herzien. Tijdens ons onderzoek bleek dat over een bedrijfsvoeringverklaring voor ketens de meningen sterk zijn verdeeld. Sommige geïnterviewden zien het als een creatieve, en als enig zinvolle, oplossing om meer grip te krijgen op de ketenbeheersing. Volgens hen zal het leiden tot meer transparantie in de besteding van gemeenschapsgeld. Anderen wijzen het nadrukkelijk af met het argument dat dit leidt tot nodeloze verhoging van de controleen regeldruk. De huidige uitvoering van het beleidscredo VBTB (Van Beleidsbegroting Tot Beleidsverantwoording),die nog niet op ketens is gericht, verloopt al niet soepel en vergt in verhouding meer tijd dan het oplevert. Ketenmanagement Aansluitend op de trend naar zelfregulering zou het voor de hand liggen dat het ketenmanagement zelf initiatief neemt voor een ketenaudit. Veel ketens zijn echter jong en beschikken nog niet over een ‘bewust’ ketenmanagement. In ons onderzoek is naar voren gekomen dat samenwerkende partijen zich vaak niet realiseren dat ze een keten vormen. Vooral op departementaal niveau is hiervan sprake. Tussen departementen vindt weliswaar beleidsafstemming plaats, maar dit wordt niet gezien als ketensamenwerking. De splitsing tussen beleid en uitvoering binnen de rijksoverheid speelt al enige jaren. De auditfunctie vindt vooral plaats op uitvoeringsniveau. Het opstellen en evalueren van beleid gebeurt vooral op bestuurlijk niveau. In de praktijk bestaan meestal geen mechanismen die zorgen

voor een koppeling tussen beleid en uitvoering. De auditor zou wel oog moeten hebben voor de kloof tussen operationeel en bestuurlijk niveau. Auditdiensten Enkele onderzochte auditdiensten zien ketenauditing als een vervolgstap op het procesmatig denken. Dit zijn auditdiensten die al ervaring hebben met het auditen van bedrijfsprocessen (operational auditing). In een keten is sprake van een bedrijfsproces dat over organisatiegrenzen heen loopt. In dat geval is auditing binnen een keten aan de orde. Dit is volgens onze opvatting synoniem aan ketenaudit. Deze auditdiensten stellen echter wel als voorwaarde dat de probleemeigenaar van de auditresultaten vooraf bekend dient te zijn. Dit is belangrijk omdat de verhoudingen zowel in de keten als binnen het opdrachtgeverschap in de praktijk vaak onduidelijk en complex zijn. Keteninformatisering Binnen de overheid zijn veel ketens aanwezig waarin de informatie-uitwisseling is geautomatiseerd. Een voorbeeld is de jeugdstrafrechtketen waarin politie, ministerie van Justitie, reclasseringsdiensten, gemeenten en opvangtehuizen gegevens met elkaar uitwisselen. Bij de automatisering van deze ketens komt het extra aan op het stroomlijnen van de gegevensuitwisseling (met het oog op snelle dienstverlening) en het beveiligen van gegevens (met het oog op privacybescherming). Van de bovengenoemde invalshoeken hebben wij twee uitgekozen waarop we ons in dit artikel nader gaan richten. In de volgende paragraaf zullen wij stil staan bij keteninformatisering omdat daarbinnen al sprake is van enige theorievorming. In de twee daarop volgende paragrafen gaan wij nader in op de aanpak en de rol van de auditdiensten tijdens een ketenaudit.

Keteninformatisering en informatieketens Centraal in deze paragraaf staat het onderwerp keteninformatisering. Er bestaat een onderscheid tussen keteninformatisering en informatieketen. Keteninformatisering Keteninformatisering is de automatisering van keteninformatie. Keteninformatie is de betekenis die een ketenpartner toekent aan de gegevens die door een voorgaande schakel in de keten zijn verwerkt, door middel van afspraken over welke gegevens wanneer aan wie worden geleverd en hoe deze gegevens dienen te worden

33

34


geïnterpreteerd en gepresenteerd [REIJ04]. Simpel gezegd is de keteninformatisering de automatisering van een al bestaande keten waarbij de automatisering als doel heeft het proces van die keten te ondersteunen. Informatieketen In geval van een informatieketen is het primaire proces: de gegevensuitwisseling. In een informatieketen staat dus het uitwisselen van gegevens centraal. Daarom kan ook worden gesproken van een gegevensketen. Een voorbeeld hiervan is de centrale salarisverwerking van een viertal departementen. De vier betrokken departementen leveren volgens afspraak op vaste tijden gegevens aan een centraal facilitair salarisbureau dat ze vervolgens verwerkt. Hierboven hebben we het verschil aangegeven tussen keteninformatisering en informatieketen. Grijpink heeft de volgende vier toetsingsinstrumenten ontwikkeld om keteninformatiseringsprojecten meer kans van slagen te geven [GRIJP02]. • Doelprofiel Het keteninformatiseringssysteem moet onmisbaar zijn voor het oplossen van het dominante ketenprobleem. • Het samenwerkingsprofiel Het keteninformatiseringssysteem moet haalbaar zijn bij de huidige ontwikkelingsgraad in die keten. • Het coördinatieprofiel Keteninformatisering moet nodig zijn voor het coördinatiestelsel van een keten. • Het informatieprofiel Het keteninformatiesysteem moet nodig zijn om de breuklijnen in de informatiehuishouding van de keten te kunnen overbruggen. Als aan alle vier de profielen wordt voldaan heeft de automatisering van een keten kans op succes. Echter, deze toetsingsmodellen hebben alleen betrekking op het operationele proces. Daarnaast is natuurlijk ook een goede bestuurlijke afstemming vereist. Grijpink wijst in dit verband op drie modellen voor het typeren van de bestuurlijke afstemming. Als sprake is van geen enkele vorm van bestuurlijke afstemming spreekt hij van het grabbeltonmodel. Wanneer echter bewuste bestuurlijke afstemming plaatsvindt, is er sprake van positionering. Ideaal is bewuste bestuurlijke afstemming met toekomstvisie. Grijpink duidt deze ideale situatie aan met golfmodel. Zowel het operationele proces als de bestuurlijke afstem-

ming dienen dus te worden bewaakt. Daarvoor onderscheidt Grijpink een drietal meetgebieden: • Infrastructureel Hoe sluiten systemen op elkaar aan. Grijpink heeft een methode ontwikkeld voor deze aansluiting. Zijn uitgangspunt is dat elke zelfstandige organisatie het eigen systeem aanhoudt. Via een aparte index/sleutel zijn de systemen van de samenwerkende organisaties aan elkaar te verbinden. • Maatschappelijk Dit betreft het waarborgen van veiligheid en privacy. • Bestuurlijk Via bestuurlijke informatie en andere indicatoren zoals werkoverleg en informeel contact kan de mate van bestuurlijke afstemming worden vastgesteld. Grijpink heeft zijn theorie ontwikkeld als reactie op het feit dat veel ambitieuze samenwerkingsprojecten binnen de overheid zijn gesneuveld, mede op grond van een gebrekkige keteninformatisering. Naar onze mening heeft Grijpink niet een concreet toetsingsmodel ontwikkeld maar veeleer een analysemodel opgesteld om na te gaan wat zich tijdens de problematiek rondom keteninformatisering afspeelt. Wel denken we dat de theorie van Grijpink voor auditors en met name IT-auditors bruikbaar is om als uitgangspunt te dienen bij het uitvoeren van een ketenaudit naar de betrouwbaarheid van het proces en het ondersteunende informatiesysteem (bijvoorbeeld het systeem dat de Belastingdienst en het ministerie van VROM ontwikkelen voor de uitvoering van de huursubsidie). Reijers is in zijn afstudeerscriptie voor de EDP-Auditopleiding aan de Erasmus Universiteit nader ingegaan op de toepassing van de theorie van Grijpink binnen de strafrechtketen [REIJ04]. Deze scriptie biedt de mogelijkheid om de zienswijze en toepassingsmogelijkheden van Grijpink in een separaat artikel aan de orde te stellen.

Opzet van een ketenaudit Op grond van literatuurstudie en interviews zijn we in ons onderzoek tot een aantal inzichten gekomen over de inhoud van en samenwerkingsvormen bij de uitvoering van een ketenaudit. Inhoud van de keten: onderzoeksobjecten Een (IT-)auditor dient bij de keuze van de onderzoeksobjecten in een ketenaudit rekening te houden met de volgende aspecten:


• Niveau van de keten Allereerst bestaat de keuze uit het niveau waarop de auditor de keten bekijkt: operationeel dan wel bestuurlijk niveau (tactisch of strategisch). • Onderzoeksaanpak; productmatig versus procesgericht Ten tweede dient een keuze te worden gemaakt uit het bestuderen van gegevensstromen en de gegevensprocessen zelf (productmatig gerichte aanpak) dan wel naar de beoordeling van beheersingsprocessen rondom de gegevensuitwisseling (procesmatig gerichte aanpak). Bij de productmatig gerichte aanpak kijken we naar de inhoudelijke kwaliteit van de gegevens, processen en systemen. Bij de procesmatig gerichte aanpak richten wij ons op het totstandkomings- en beheersingsproces van de gegevens, processen en systemen. Het gaat dan bijvoorbeeld om de kwaliteit van het systeemontwikkelingsproces. Samenwerking tijdens het uitvoeren van een ketenaudit Als wordt besloten om een ketenaudit uit te voeren is het allereerst de vraag wie dat gaat doen. Hierin bestaan verschillende mogelijkheden. • Een extern auditbureau voert de ketenaudit uit. • De auditdienst van het departement met de eindverantwoordelijkheid in de keten voert de audit uit. • De auditdiensten van alle, in de keten betrokken departementen, voeren de ketenaudit uit. Tijdens het onderzoek hebben we een conceptueel denkkader ontwikkeld om de huidige vormen van samenwerking tussen departementale auditdiensten te typeren. Dit kader bestaat uit drie modellen. Deze symboliseren het verband tussen de mate van samenwerking tussen auditdiensten en de invloed daarvan op de beschouwing van de keten als geheel. We onderscheiden de volgende drie modellen: • Het consolidatiemodel De uitvoering van het proces ligt bij het ene departement en de eindverantwoordelijkheid bij het andere. Onduidelijk is vaak wie van de twee de accountantsverklaring afgeeft, of men op elkaar een review gaat uitoefenen en wiens standaarden daarbij worden gebruikt. Het bezwaar van dit model is dat de keten als geheel niet in beschouwing wordt genomen en er geen gemeenschappelijke verklaring wordt afgegeven over de beheersing van de keten. • Het kokermodel Volgens dit model wordt binnen het ketenproces een deel

gezamenlijk en een deel afzonderlijk door de betrokken departementen uitgevoerd. Voor het afzonderlijke deel wordt een eigen accountantsverklaring afgegeven en voor het gemeenschappelijke deel een gezamenlijke. Het bezwaar van het kokermodel is dat slechts een deel van de keten gemeenschappelijk wordt beschouwd. Dit kokermodel wordt in de praktijk veel toegepast onder de vlag van een ketenaudit maar is het feitelijk niet helemaal. • Het centrifugemodel Dit is het ideale model voor de ketenaudit. Het uitgangspunt voor dit model is dat het gehele ketenauditproces gezamenlijk wordt uitgevoerd. Het belangrijke voordeel van dit model is dat het de gehele keten in beschouwing neemt en dat er voor het gehele ketenproces één gemeenschappelijke verklaring wordt opgesteld. Voorwaarde bij het hanteren van het centrifugemodel is wel dat vooraf een uitgebreid plan van aanpak aanwezig is waarin de interne afstemming tussen auditors zorgvuldig is geregeld. De onderzoeksresultaten in ons rapport geven aan dat de auditdiensten ketenaudits uitvoerbaar vinden wanneer wordt voldaan aan voorwaarden zoals een duidelijke rol van de auditdienst en een duidelijk opdrachtgeverschap van de ketenaudit. Ook moet vooraf rekening worden gehouden met complicerende factoren zoals de complexe verantwoordelijkheidsverdeling in een keten. Verder vindt men ketenaudits pas zinvol als de beheersing zich richt op de keten als geheel en als er sprake is van een gesloten managementcyclus binnen de keten. Omdat de resultaten van een audit politieke gevoeligheden kunnen oproepen tussen ketenpartners wordt aangeraden om ketenaudits pas uit te voeren wanneer de onderlinge relaties voldoende hecht zijn. Ten slotte zijn wij van mening dat de meerwaarde van een ketenaudit schuilt in het volgende. Vanwege het feit dat een ketenproces over verschillende departementen loopt, zijn tevens verschillende auditdiensten bij de controle van het proces betrokken. Om het gehele proces en met name de betrouwbaarheid van de schakels (overdrachtsmomenten) te kunnen beoordelen, dienen de auditdiensten gezamenlijk het gehele proces te beoordelen. Wanneer iedere auditdienst zich beperkt tot het ‘eigen’ departement is het gevaar aanwezig dat de auditbenadering te fragmentarisch blijft en de overdrachtsmomenten van informatie en resultaten tussen de ministeries niet of onvoldoende in de beoordeling worden meegenomen.

Best practices Tot slot van dit artikel geven wij de ‘best practices’, die gelden als een van de eindresultaten van ons onderzoek.

35

36


Wij hebben daarbij een onderscheid gemaakt tussen de inhoudelijke kant en de procesmatige kant van een ketenaudit. Deze best practices zijn tot stand gekomen op grond van analyse van de literatuur en toetsing in de praktijk (ketenaudits die tijdens het onderzoek werden uitgevoerd). Draagvlak bij ketenbetrokkenen (inhoudelijk) Geïnterviewden geven aan dat de ketensamenwerking afhankelijk is van de mate waarin medewerkers op sleutelposities in de keten met elkaar kunnen samenwerken, afspraken worden nageleefd, dezelfde definities worden gebruikt en men zich bewust is van cultuurverschillen. De ketensamenwerking kan aan effectiviteit en efficiëntie verliezen indien een dominante partij binnen de keten als ketenregisseur optreedt; dit roept te veel weerstand op bij de overige ketenpartners. Een oplossing voor dit probleem kan zijn dat de aansturing van de keten buiten de keten zelf wordt geplaatst. Taken, verantwoordelijkheden en bevoegdheden (inhoudelijk) Van belang voor het succes in een keten zijn duidelijk (vastgelegde) afspraken ten aanzien van taken, verantwoordelijkheden en bevoegdheden bij de beheersing van een keten. Dit vereist tevens duidelijke verhoudingen en communicatie tussen verschillende bestuurslagen. Vooraf daaraan zijn bij alle ketenpartners vereist: eensgezindheid ten aanzien van ketenvisie, waarden en normen, het beoogde ketendoel, de ketendoelgroep en het ketenbeleid.

Verdeling van de verantwoordelijkheden bij de uitvoering van een audit (procesmatig) Vooraf moet duidelijkheid bestaan over de structuur van de audituitvoering. Dit is vooral van belang als de uitvoering bij het ene en de bestuurlijke verantwoordelijkheid bij het andere departement ligt. Welk departement moet de audit uitvoeren? Bij een financial audit komt dit prominent naar voren door de accountantsverklaring. De auditor/accountant die de accountantsverklaring afgeeft moet beslissen op welke manier hij de deugdelijke grondslag vormgeeft. Hierbij is het dilemma of hij steunt op een accountantsverklaring van het ‘andere departement’, dan wel zelf onderzoek uitvoert om bij dat andere departement feiten en bevindingen boven tafel te krijgen. De speelruimte voor de financial auditor is gering. De speelruimte voor de operational auditor lijkt ruimer, maar ook hier is sprake van oordeelsvorming door de auditor van ‘het andere departement’, en van het steunen op bevindingen van collega-auditors. Eigenaar van de auditresultaten (procesmatig) Het benoemen van het eigenaarschap van de auditresultaten blijkt in de praktijk een duidelijke succesfactor te zijn voor het slagen van een ketenaudit. Als gevolg van de gekozen verdeling van verantwoordelijkheden komt gedeeld eigenaarschap voor. Het is zaak dit gedeelde eigenaarschap vooraf expliciet vast te leggen in het plan van aanpak.

Goede koppeling tussen de ketenschakels (inhoudelijk) Bij ketenprocessen zijn de interfaces (koppelpunten) een wezenlijk onderdeel van het eindresultaat van de keten. Daarom dient veel aandacht te worden besteed aan de beheersing hiervan; vooral aan de controlemaatregelen voor deze interfaces. Deze moeten goed en tijdig worden beschreven.

Samenstelling van het auditteam (procesmatig) Met een auditteam dat is samengesteld uit auditors van meer dan één departement is het mogelijk om de inzet van auditors zodanig te rouleren dat de eigen dienst niet hoeft te worden beoordeeld (vreemde ogen dwingen). Dit zou kunnen dienen als waarborg voor het verminderen van verschillen in interpretatie, werkwijze en normen tussen auditoren. In theorie geeft deze aanpak voordelen. In de praktijk blijkt deze lastig uit te voeren.

Maatschappelijke en politieke gevoeligheden (procesmatig) De samenwerking tussen departementen in een keten kunnen bepaalde processen dan wel bepaalde proceskoppelingen tussen departementen te gevoelig liggen, waardoor het niet gewenst is daar een ketenaudit op uit te voeren. Door goede afspraken te maken over het object en de aspecten van onderzoek wordt gezocht naar een oplossing van dit probleem. Dit kan betekenen dat de audit zich in de uitvoering beperkt tot een omgevingsanalyse of een risicoanalyse. De toegevoegde waarde van een dergelijke audit/risicoanalyse is lager, maar in die omstandigheden wel het hoogst haalbare.

Samenwerking binnen het auditteam (procesmatig) Geïnterviewden geven aan dat ze bij het uitvoeren van een ketenaudit, ten aanzien van de benadering en werkwijze, aanlopen tegen verschillen tussen auditdiensten en auditoren. Cultuur- en organisatieverschillen zijn daarvan gedeeltelijk de oorzaak. Voorbeelden van een uiteenlopende auditaanpak zijn: gegevensgericht versus risicogericht; proactief versus reactief. De verschillen in de auditaanpak vormen pas echt een probleem als het wij/zij-gevoel overheerst. Dit kan worden doorbroken door medewerkers vanuit verschillende organisatieonderdelen in werkgroepen met elkaar te laten samenwerken. Daardoor verminderen de cultuurverschil-


len en neemt de betrokkenheid voor het geheel toe. Verder kan het plan van aanpak in de voorbereidende fase dienen als instrument om overeenstemming te krijgen over de auditaanpak. Dit betekent wel dat vooraf duidelijk moet zijn aan welke eisen een plan van aanpak moet voldoen. Ook hierover kan uiteraard verschil in opvatting bestaan. Afstemming met de opdrachtgever (procesmatig) Geïnterviewden vinden het plan van aanpak een belangrijk middel om in de voorbereidingsfase af te stemmen met de opdrachtgever. In het plan van aanpak moeten allerlei afspraken over inhoud, voortgang, afstemming en randvoorwaarden nauwkeurig worden vastgelegd. Door het grote aantal betrokkenen, de ingewikkelde verhoudingen en eventuele politieke gevoeligheden is het van belang dat dit zorgvuldig en gedetailleerd gebeurt. Daarnaast moet men tussentijds de uitvoering en het plan van aanpak evalueren en eventueel bijsturen. Er moet een regulier overleg van het interdepartementale auditteam zijn. Het is verder belangrijk dat de lijn opdrachtgever/opdrachtnemer helder is en blijft. De auditor moet verder kijken dan de zaken die expliciet genoemd worden in de opdracht. Welke belangen spelen er, wie zijn de belangrijkste spelers, welke overlegorganen zijn ingesteld met welke rol. Dit betekent dat voldoende contacten moeten worden onderhouden met de opdrachtgever (Interne Stuurgroep, de Externe Stuurgroep) en eventuele andere betrokken organen. Vooral de verantwoordelijkheden en de bevoegdheden dienen dan in het oog te worden gehouden. Het dient vooraf duidelijk te zijn welke functionaris van iedere auditdienst het eindrapport zal ondertekenen. Dan is namelijk ook helder wie bij de eindredactie van het rapport betrokken moet worden. Aandacht voor kwaliteit (procesmatig) Volgens de geïnterviewden moet de aandacht voor kwaliteit uit meer bestaan dan het op papier vastleggen van kwaliteitseisen. De ketenauditor moet vooral op de werkvloer aanwezig zijn want daar hoort hij meer en kan hij ontwikkelingen en problemen sneller zien aankomen en begrijpen.

Samenvatting en conclusies Ons inventariserend onderzoek heeft het inzicht opgeleverd dat weliswaar veel theorievorming heeft plaatsgevonden betreffende de aansturing van ketens, maar dat nog geen vertaalslag is gemaakt naar ketenbeheersing. Bovendien zijn veel theorieën ontwikkeld voor vraaggerichte ketens in het bedrijfsleven. Dit is in mindere mate gebeurd voor aanbodgerichte ketens binnen de overheid.

Voorzover dit wel het geval is gaat het nog om algemene analysemodellen die nadere invulling en specificatie behoeven om als toetsings- of referentiemodel te kunnen dienen (zie bijvoorbeeld Grijpink). Hier ligt nog veel werk in het verschiet. In het volgende artikel over ketenauditing wordt een stap gedaan in de richting van een referentiemodel voor de IT-ketenaudit. Daarnaast biedt de theorie van Grijpink (zoals blijkt uit de scriptie van Reijers) een goede mogelijkheid voor een nadere uitwerking van een toetsingsmodel. Aangezien ketensamenwerking binnen de overheid oprukt, is samenwerking tussen betrokken auditdiensten en de opdrachtgever van de ketenaudit naar onze mening onontbeerlijk. Om te kunnen anticiperen op deze trend is een aantal zaken van belang. Ten eerste is dat de acceptatie door de auditdiensten van het feit dat ketenauditing een opkomende problematiek is die een nieuwe aanpak vereist. Ten tweede is dat een uitbreiding van de deskundigheid van de auditor op het gebied van ketens en ketenauditing. Ten derde is het minimaliseren van miscommunicatie tussen samenwerkende auditdiensten een belangrijke factor. Hieraan dragen bij een heldere opdrachtformulering van de ketenaudit en een duidelijke omschrijving van ketengerelateerde begrippen. De belangrijkste randvoorwaarde voor het slagen van een ketenaudit is evenwel dat de auditdiensten het onderzoek uitvoeren als een ‘joint audit’ en niet als een aaneenschakeling van single audits, waarin iedere auditdienst alleen de schakels en deelobjecten van een keten onderzoekt die binnen het eigen ministerie vallen. Dankwoord Aan het onderzoek ‘Ketenauditing nieuw en daarom spannend’ hebben behalve de auteurs ook de volgende personen meegewerkt. Zij hebben zinvolle suggesties voor de inhoud van dit artikel gegeven en de conceptversies kritisch bekeken. Onze dank daarvoor gaat uit naar: • dhr. Drs. M.S. (Menno) Toussaint RC CPC (medewerker Centrale Audit Directie, ministerie van Financiën); • dhr. Drs. A. (Ton) Reijers (auditmedewerker van de auditdienst ministerie van Jusititie); • dhr. Drs. R.G.A. (Rob) Rutten (auditmedewerker van de auditdienst ministerie van Justitie). Literatuur [ALGE04] Algemene Rekenkamer, (2004), Rechtspersonen met een Wettelijke Taak. [BZK04]

Ministerie BZK, (2004), Ruimte voor regie.

[FIN00]

Ministerie van Financiën, (2000), Handleiding Government Governance, directie ATB.

37

38


[FIN04]

Ministerie van Financiën, (2004), Ketenauditing:

Noot

nieuw en daarom spannend.

1 Dit artikel is een samenvatting van een inventariserend

[GRIJP02] Grijpink, J., (2002), Informatiestrategie voor [REIJ04]

onderzoek naar ketenauditing bij de rijksdienst

ketensamenwerking. (RWT), deel 4.

(‘Ketenauditing, nieuw en daarom spannend’, Ministerie

Reijers, A., (2004), Keteninformatisering en keten-

van Financiën, juni 2004).

auditing.

Overige literatuur Duivenbode, H. van en M. Lips, (1999), Ketenmanagement in de publieke sector. Folkerts e.a., (1996), Bouwen aan marktgerichte ketens. Grijpink, J., (2004), Keteninformatisering I en II informatieinfrastructuren voor betere privacybescherming, maart. IBO, (2004), Rapport Controletoren: vermindering controleen regeldruk. INK, (2004), Brochure Ketenmanagement. Interdepartementale Beleidsonderzoeken, (2003), Nr. 1, Brief van de minister van Financiën, 26 september, nr. 28 229. Ministeries VROM, V&W, BZK, EZ en Financiën, (2003), Rijksvisie drinkwaterketen. Montfoort, C. van, (2004), Verbreding van de publieke verantwoording. Northedge, (2002), Voorstel ten behoeve van de inzet van het INK-model voor ketenontwikkeling in de veiligheid en justitiele keten, Werkgroep veiligheidsketen van het INK (vanuit het INK: Prof. Dr. H. Luijten, vz.; Drs. H. van Houcke, secr.; Drs. D.P. Noordhoek, auteur). PAO, (2004), Rapport over het delegeren van overheidsverantwoordelijkheden; onder andere ook bespreking van de ketenaudit Jeugdcriminaliteit. Vermont, H., (2004), Nieuwe Reveil, nr. 2. Willems, F. en W. Opheij (Twynstra Gudde Managementconsultants), (2004), Shared Servicecentrers: Balanceren tussen Macht en Pracht.


39

Virtualisatie en de IT-auditor Virtualisatie is het gebruik van software om hardware of een gehele computeromgeving anders dan die waar de software feitelijk op 1 draait, te emuleren . In het geval dat een heel systeem wordt

geëmuleerd, wordt vaak gesproken over een virtuele machine. Een virtuele machine kan bestaan naast reguliere applicaties die actief zijn op een computersysteem. Dit artikel gaat in op virtualisatie van Bert Rechter

systemen met virtuele machines op basis van software.

Inleiding In dit artikel zal worden ingegaan op de achtergrond en historie van het concept virtualisatie en wordt een introductie gegeven op de werking van het concept virtualisatie. Vervolgens komen de mogelijke toepassingen, voor- en nadelen van het gebruik van virtualisatie, en de invloed die virtualisatie heeft op de audit-aanpak bij het beoordelen van omgevingen waar virtualisatie wordt toegepast aan bod. Daarnaast wordt een overzicht gegeven van veel voorkomende virtualisatiesoftwareproducten.

Achtergrond en historie De techniek van virtualisatie is afkomstig van mainframe systemen waar het ‘Dynamic Logical Partitioning’ (kortweg LPAR) heet. IBM heeft deze techniek ontwikkeld om timesharing mogelijk te maken op mainframes. In het verleden hadden veel organisaties maar één mainframe en dit mainframe werd gebruikt voor zowel ontwikkeling, test als productie2. Met de LPAR-functionaliteit kunnen meerdere virtuele omgevingen op hetzelfde mainframe worden gebruikt. Later (in 1999) is deze techniek ook beschikbaar gekomen op IBM AS/400-systemen. Tegenwoordig is virtualisatie mogelijk op vrijwel alle midrange-systemen van IBM3 en bieden ook andere leveranciers soortgelijke functionaliteit op hun systemen.

Het concept virtualisatie De werking van virtualisatie De werking van virtualisatie is gebaseerd op een extra laag besturingssoftware (eigenlijk een soort besturingssysteem op zichzelf) bovenop het bestaande besturingssysteem waarin virtuele machines worden gedefinieerd.

Drs B.J. Rechter RE is werkzaam als Projectmanager EDP Audit bij Ernst & Young EDP Audit in Den Haag. Hij heeft dit artikel op persoonlijke titel geschreven.

Een virtuele machine is een logische representatie van een fysiek computersysteem met alle bijbehorende eigenschappen. Binnen een virtuele machine wordt vervolgens een besturingssysteem (bijvoorbeeld Windows 2003 Server) geïnstalleerd. Schematisch ziet virtualisatie er uit als in figuur 1.

Applicatie

Applicatie Applicatie



BesturingsBesturingssysteem Systeem (bv.Windows (bv.Windows NT4) NT4)

BesturingsBesturingssysteem Systeem (bv. (bv. Linux) Linux)

BesturingsBesturingssysteem Systeem (bv.Windows (bv.Windows 2003) 2003)

Intel Architectuur

Virtualisatie Virtualisatie software

Besturingssysteem Hardware Figuur 1. Schematische weergave van een virtuele omgeving Figuur 1 geeft een schematische weergave van de onderdelen van een mogelijke virtuele omgeving. In deze figuur is de applicatie aan de linkerkant een applicatie die rechtstreeks op het besturingssysteem draait dat in de tweede laag zit. De drie applicaties rechtsboven draaien allemaal op een besturingssysteem in een virtuele machine. Gemeenschappelijk gebruik hardware Voordat een besturingssysteem kan worden geïnstalleerd, moet worden geconfigureerd welke hardware voor de virtuele machine beschikbaar is (bijvoorbeeld aantal en omvang van de harde schijven, netwerkkaarten, communicatiepoorten zoals USB en seriële/parallelle poorten en overige randapparatuur zoals een diskettedrive). Deze configuratieslag is nodig om te voorkomen dat de virtuali-

40


satiesoftware altijd alle mogelijke randapparatuur van een virtuele machine moet koppelen aan hardware van de fysieke server. Een dergelijke aanpak zou een flinke aanslag op de performance van de virtuele machines betekenen, omdat de virtualisatiesoftware iedere keer als er iets gebeurt op de server hardware dit door moet geven aan de virtuele machine. De virtualisatiesoftware zorgt er op basis van de hardware configuratie per virtuele machine voor dat het gemeenschappelijke gebruik van hardware door meerdere virtuele machines in goede banen wordt geleid. Scheiding van virtuele machines Om de bestanden van verschillende virtuele machines van elkaar te scheiden, wordt schijfruimte veelal gesimuleerd door middel van een bestand. Hierbij wordt voor ieder volume (te vergelijken met de letter die in Windows aan een harde schijf wordt toegewezen) een separaat bestand gebruikt. Eventueel is het ook mogelijk direct gebruik te maken van een fysieke harde schijf in het systeem. Dit is echter niet aan te raden omdat dan geen zekerheid bestaat dat de bestanden van de virtuele machines onderling en die van het onderliggende besturingssysteem van elkaar gescheiden blijven. De virtualisatiesoftware zorgt ervoor dat de verschillende virtuele machines van elkaar zijn gescheiden. Deze scheiding wordt gerealiseerd doordat de virtualisatiesoftware bepaalde systeeminstructies4 afvangt en eventueel simuleert. Dit betreft systeeminstructies die niet zonder meer kunnen worden uitgevoerd omdat het effect ervan zou kunnen doorwerken op andere virtuele machines (bijvoorbeeld directe toegang tot hardware). Omdat het afvangen van alle systeeminstructies een enorme vertraging zou betekenen, worden de meeste ‘normale’ systeeminstructies direct op het systeem zelf uitgevoerd zonder tussenkomst van de virtualisatiesoftware. In de praktijk betekent dit dat één virtuele machine kan ‘crashen’ (bijvoorbeeld een blauw scherm in Windows) zonder dat dit invloed heeft op de andere virtuele machines die actief zijn. Om te voorkomen dat één virtuele machine alle systeembronnen (processortijd en intern geheugen) gebruikt zodat de andere virtuele machines effectief niet meer functioneren, is het mogelijk beperkingen in te stellen op het gebruik van intern geheugen en processortijd.

Toepassingen Server consolidatie In de afgelopen jaren is een sterke trend zichtbaar in de ontwikkeling van serverhardware waarbij relatief steeds meer capaciteit beschikbaar komt voor een nagenoeg gelijke prijs. Voor een geringe meerprijs is zelfs een

forse hoeveelheid extra capaciteit verkrijgbaar. Deze ontwikkeling maakt het mogelijk meerdere applicaties op dezelfde fysieke server te draaien. In veel gevallen is dit echter geen bevredigende oplossing omdat één applicatie nu de correcte werking van alle andere applicaties op die server kan verhinderen. Ook kunnen sommige applicaties niet op hetzelfde systeem naast elkaar worden gebruikt vanwege specifieke afhankelijkheden (denk bijvoorbeeld aan verschillende versies van een databasemanagementsysteem die niet tegelijkertijd binnen één besturingssysteem actief kunnen zijn). In deze gevallen biedt het gebruik van virtualisatie een oplossing. Door het gebruik van virtualisatiesoftware en meerdere virtuele machines zijn er geen beperkingen meer om meerdere applicaties binnen één besturingssysteem te gebruiken. Ook is via de virtualisatiesoftware de onderlinge invloed van applicaties beperkt tot performance omdat alle applicaties uiteindelijk nog wel van dezelfde hardware gebruikmaken. Scheiding van ontwikkel/test/productie omgevingen Omdat virtuele machines volledig van elkaar gescheiden kunnen worden, biedt virtualisatie de mogelijkheid om op één fysiek computersysteem meerdere gescheiden omgevingen te creëren, bijvoorbeeld een ontwikkel/testomgeving en een productieomgeving. Met name in kleinere bedrijven, waar vaak niet zo veel verschillende computersystemen beschikbaar zijn, kan zo toch een vrijwel fysiek gescheiden testomgeving worden gerealiseerd. Scheiding ontwikkel/productieomgeving voor softwareontwikkelaars Bij het testen van nieuwe of aangepaste programmatuur kunnen fouten optreden die de stabiliteit van het besturingssysteem kunnen aantasten. Ook is het voor softwareontwikkelaars vaak wenselijk om volledige beheerderrechten op de eigen pc te hebben om de nieuwste ontwikkelgereedschappen zelf te kunnen installeren. Veel beheerders hebben daarom een extra pc op hun bureau staan omdat het niet wenselijk is de standaard kantoor pc te gebruiken. Door gebruik te maken van virtualisatie kan op één (weliswaar iets krachtiger pc) een extra omgeving worden aangemaakt voor systeemontwikkeling. De ontwikkelaar heeft volledige controle over deze omgeving zonder dat deze invloed heeft op de standaard kantoorautomatiseringomgeving. Ook kan gemakkelijk een back-up worden gemaakt, door het kopiëren van het bestand dat de harde schijf van de virtuele machine bevat samen met de bijbehorende configuratiebestanden. Het herstellen van de virtuele omgeving na een fout is dan relatief eenvoudig


doordat alleen de juiste bestanden moeten worden teruggezet om weer een goed werkende omgeving te krijgen. Consolidatie externe koppelingen Met name bij banken en verzekeraars worden veel koppelingen met externe netwerken gebruikt die in sommige gevallen ook nog een eigen server hebben voor het verwerken van de gegevens. Zonder virtualisatie zijn hiervoor allemaal aparte servers (of soms gewoon losse standaard pc’s) nodig die al dan niet aan het reguliere netwerk zijn gekoppeld via een firewall. Meestal vragen deze toepassingen niet veel rekenkracht, waardoor ze via virtualisatie relatief eenvoudig te consolideren zijn op één fysieke server. Daar waar sprake is van gescheiden netwerken is wel van belang dat de fysieke server over voldoende netwerkkaarten beschikt om de verkeersstromen fysiek te scheiden. Iedere virtuele machine moet dan wel de beschikking hebben over een separate netwerkkaart.

Voor- en nadelen van virtualisatie Afhankelijk van de situatie kan het gebruik van virtualisatie voordelen bieden. In alle gevallen zijn er echter ook nadelen aan het gebruik van virtualisatie verbonden. Hierna is een overzicht opgenomen van de belangrijkste voor- en nadelen van de toepassing van virtualisatie. Voordelen • Er is minder hardware nodig Door het consolideren van meerdere servers in meerdere virtuele machines op één server met virtualisatiesoftware is nog maar één fysieke server nodig. Dit betekent minder onderhoudskosten en een overzichtelijker serverruimte. • Het maken en het beheer van back-ups wordt makkelijker Doordat alle software en data op een server staat is het eenvoudig om een back-up te maken en deze weer terug te zetten. Het maken van een back-up van de gehele virtuele machine kan eenvoudig worden uitgevoerd door het kopieren van één bestand. • Vergemakkelijkt en versnelt uitwijk Het is niet meer noodzakelijk om alle systemen afzonderlijk op te bouwen als vooraf kopieën zijn gemaakt van de virtuele machines. Een standaard server met voldoende capaciteit is dan voldoende om de virtualisatiesoftware te installeren en de virtuele machines terug te zetten. Om dit proces verder te vergemakkelijken en versnellen kan vooraf een ‘image’ (digitale kopie van de gehele harde schijf van een server) worden gemaakt van de host server waarop de virtuele machines draaien. In geval van uitwijk wordt dan alleen dit image teruggezet om weer een server beschikbaar te hebben als basis voor de virtuele machines.

Nadelen • Toegenomen afhankelijkheid van hardware Meerdere applicaties zijn bij toepassing van virtualisatie afhankelijk van één enkel fysiek apparaat. Als hardware van de server niet meer functioneert, treft dit gelijk alle virtuele machines die actief zijn op die server. Om dit risico te beperken zijn extra maatregelen wenselijk, zoals een dubbele voeding en redundante harde schijven (bijvoorbeeld via RAID-5 technologie waarbij de gegevens zo zijn verdeeld dat bij uitval van één schijf de gegevens nog beschikbaar zijn op de andere schijven). •Additioneel beheer voor de virtuele machines en virtualisatiesoftware Hoewel het fysieke beheer makkelijker is geworden, moet ook een additionele beheerinspanning worden geleverd, namelijk het beheer van de (configuratie van de) virtuele machines en van de virtualisatie software zelf. De hoeveelheid werk die dit met zich meebrengt is met name afhankelijk van de snelheid waarmee het gebruik van de virtuele machines toeneemt en/of er nieuwe virtuele machines bijkomen. Afhankelijk van de stabiliteit van de IT-omgeving voor wat betreft groei in gebruik en aantal en aard van de applicaties is dit meer of minder werk. Bijvoorbeeld bij een sterke groei in het gebruik kan het nodig zijn dat een virtuele machine meer systeembronnen zoals schijfruimte en intern geheugen krijgt toegewezen.

Virtualisatie en de IT-auditor Het gebruik van virtualisatie heeft uiteraard invloed op ons werk als IT-auditor. In deze paragraaf zal worden ingegaan op de invloed die virtualisatie heeft op de automatiseringsomgeving en de consequenties die dit heeft voor het werk van de IT-auditor. De invloed die virtualisatie heeft op een specifieke automatiseringsomgeving is enerzijds afhankelijk van de specifieke doelstelling die men daarmee heeft (bijvoorbeeld voor serverconsolidatie of juist voor scheiding van test en productieomgeving) en anderzijds van het product dat wordt gebruikt. Onafhankelijk van het gebruik van virtualisatie en van het product dat wordt gebruikt zijn de volgende punten van belang: • Beheer van de virtualisatiesoftware Met het gebruik van virtualisatie is ook extra software geïntroduceerd: de virtualisatiesoftware. Aangezien deze software het kloppend hart is van de virtuele machines is het van groot belang dat deze software goed wordt beheerd. Aandachtspunten zijn met name configuratie- en versiebeheer omdat onzorgvuldig doorgevoerde wijzigingen in de configuratie (denk aan het wijzigen van de hoe-

41

42


veelheid beschikbaar geheugen of netwerkinstellingen) en/of de softwareversie grote gevolgen kunnen hebben voor de werking van de virtuele machines. • Beperken van toegang tot de management console Alle virtualisatieproducten maken gebruik van een al dan niet geïntegreerde managementconsole waarmee de virtuele omgeving kan worden beheerd. Vanuit deze console kunnen virtuele machines worden toegevoegd en verwijderd en kan ook de configuratie van iedere virtuele machine worden aangepast. Punt van aandacht is ook het gebruik van een beveiligde verbinding voor remote toegang tot de management console en virtuele machines. Het gebruik van een beveiligde verbinding is meestal een standaardinstelling die echter ook kan worden uitgeschakeld. Ongeautoriseerde toegang tot de managementconsole betekent dat instellingen kunnen worden aangepast die de betrouwbare werking van de virtuele omgeving aan kunnen tasten of de beschikbaarheid in gevaar kunnen brengen. Om het risico te beperken moet de toegang tot het account voor de managementconsole worden beperkt tot een zo klein mogelijke groep beheerders en dient het gebruik van dit account te worden gelogd. • Beveiliging van (configuratie)bestanden van virtuele machines In aanvulling op de afscherming van de management console is het van belang de configuratiebestanden en de bestanden met de inhoud van de virtuele machine zelf goed af te schermen door de toegang te beperken tot het beheerdersaccount (‘root’ in Unix of ‘Administrator’ in Windows). Ongeautoriseerde wijziging van configuratiebestanden kan de betrouwbare werking van de virtuele machine in gevaar brengen. Ongeautoriseerde wijziging in bestanden met de inhoud van de virtuele machine kunnen de integriteit van die bestanden aantasten waardoor de virtuele machine niet meer bruikbaar is. • Scheiding van bestanden tussen de virtuele machines Voor welke toepassing virtualisatie ook wordt gebruikt, scheiding van bestanden tussen de virtuele machines is van belang om te voorkomen dat ze óf afhankelijk van elkaar worden óf elkaars werking zouden kunnen beïnvloeden. Voor de IT-auditor is van belang dat hij nagaat op welke wijze de bestanden zijn gescheiden. Hiertoe is allereerst van belang welk product wordt gebruikt en afhankelijk van het product kan vervolgens worden bepaald op welke wijze de bestanden gescheiden kunnen worden. •Aanwezigheid van back-ups van de configuratie van de virtuele omgeving Het opnieuw inrichten van de virtuele omgeving is een tijdrovende klus en foutgevoelig vanwege de vele instel-

lingen die moeten worden nagelopen en mogelijk aangepast. In aanvulling op de reguliere back-ups van de inhoud van de virtuele omgevingen is het dus van belang dat goede back-ups aanwezig zijn van configuratie van de virtuele omgeving. Naast de genoemde punten is het van belang dat het gebruik van virtualisatie tijdig (nog vóór het plannen van de audit) wordt herkend: met name in AS/400-omgevingen valt een partitie niet zonder meer als zodanig te herkennen en bestaat het risico dat wordt voorbijgegaan aan de invloed van virtualisatie, terwijl dit wel had gemoeten. Om dit risico te beperken kan het beste bij het in kaart brengen van de te onderzoeken omgeving expliciet worden nagegaan of sprake is van virtualisatie. Om een juiste beoordeling te kunnen uitvoeren van de configuratie van de virtualisatiesoftware is voldoende kennis van de gebruikte virtualisatiesoftware noodzakelijk, vooral ook vanwege de specifieke eigenschappen en mogelijkheden van de virtualisatiesoftware die verschilt per leverancier. De IT-auditor dient zich dus van te voren voldoende te verdiepen in de te onderzoeken situatie en zich ervan te vergewissen dat of hijzelf voldoende kennis heeft of dat hij een specialist inschakelt met voldoende kennis. Bij het herkennen van virtualisatiesoftware kan het volgende overzicht van virtualisatieproducten behulpzaam zijn: • Virtualisatie op IBM-systemen Gezien de oorsprong van virtualisatie bij IBM Mainframes mag het geen verbazing wekken dat IBM’s virtualisatie techniek ‘Dynamic Logical Partioning (LPAR)’ op de nieuwste IBM midrange hardware (de i5 series) ondersteuning biedt voor IBM i5/OS (de nieuwste versie van wat voorheen OS/400 heette), AIX (IBM’s Unix variant) en Linux (een public domain Unix variant)5. • Virtualisatie op Intel systemen Voor op Intel-processoren gebaseerde hardware zijn er twee producten: VMWare6 en Microsoft Virtual Server 20057. Microsoft Virtual Server 2005 wordt als extra software geïnstalleerd bovenop Windows 2003 Server. In principe ondersteunt Microsoft Virtual Server 2005 alleen Windows besturingssystemen, maar in Servicepack 1, dat later dit jaar uitkomt, is ondersteuning voor Linux ingebouwd. VMware ondersteunt vrijwel alle voor Intel beschikbare besturingssystemen en heeft meerdere virtualisatie producten: • VMWare Workstation VMWare Workstation is gericht op desktop systemen en wordt geïnstalleerd bovenop een bestaand besturingssysteem. De console van de virtuele machines is alleen bruikbaar vanaf het eigen systeem en kan niet vanaf


afstand worden benaderd. Deze versie is met name gericht op IT-professionals zoals systeembeheerders en systeemontwikkelaars die behoefte aan flexibele gescheiden testen/of ontwikkelomgeving hebben, maar geen extra hardware kunnen of willen aanschaffen. • VMWare GSX server VMWare GSX Server is bedoeld voor de professionele markt. Deze versie wordt net als VMWare Workstation geïnstalleerd bovenop een bestaand besturingssysteem. De console van de virtuele machines is desgewenst vanaf afstand te gebruiken met een ‘Remote Console’ functionaliteit over een beveiligde verbinding. Deze versie is gericht op server consolidatie en het vergemakkelijken van softwareontwikkeling. • VMWare ESX server Dit is het paradepaardje van VMWare, bedoeld voor gebruik met bedrijfskritische applicaties. Deze versie wordt direct op de hardware geïnstalleerd zonder dat eerst een besturingssysteem aanwezig moet zijn. VMWare ESX server maakt hiervoor gebruik van een eigen aangepaste versie van Linux. Naast de functionaliteit van GSX Server biedt deze versie mogelijkheden voor zero-downtime onderhoud en load-balancing van virtuele machines over meerdere processoren en meerdere VMWare ESX Servers. Voor zero-downtime onderhoud kunnen de activiteiten van een virtuele machine op één ESX server door een realtime kopie van deze virtuele machine op een andere ESX server worden overgenomen. Vanwege de uitgebreide functionaliteiten en additionele ondersteuning voor gebruik met meerdere servers is deze versie ook zeer geschikt voor gebruik in rekencentra. • Overige(systemen Tegenwoordig bieden alle grote leveranciers van (op Unix) gebaseerde systemen wel functionaliteit aan voor virtualisatie. Meestal noemen ze dit partitioning. Hierna is een overzicht van de meest voorkomende Unix-varianten met de naam waaronder de ondersteuning voor virtualisatie wordt geleverd: • HP-UX 11i: HP Virtual Server Environment8; • Sun Solaris 10: Solaris Containers (geen volledige virtualisatie van een systeem)9; • OpenVMS: OpenVMS Galaxy soft partitions10.

ieder denkbaar platform en wordt steeds vaker toegepast als kostenbesparende oplossing voor het consolideren van servers of het realiseren van gescheiden omgevingen. Voor de IT-auditor betekent dat in ieder geval dat hij zich bewust moet zijn van de mogelijkheid dat sprake is van virtualisatie in een te beoordelen omgeving. Daar waar virtualisatie wordt toegepast betekent dit verder dat extra werkzaamheden moeten worden verricht om inzicht te krijgen in de maatregelen die zijn getroffen rondom virtuele machines en in de virtualisatiesoftware. Om een goede beoordeling van deze maatregelen te kunnen uitvoeren is voldoende kennis van zaken nodig bij de IT-auditor of moet deze een specialist inschakelen die over deze specifieke materiekennis beschikt. Noten 1 Deze definitie is uit het Engels vertaald op basis van de definitie op SearchStorage.com onder ‘virtualization’, http://www.searchstorage.com, juni 2005. 2 R. Rose, ‘Survey of System Virtualization Techniques’, http://www.robertwrose.com/vita/rose-virtualization.pdf, maart 2004. 3 Op basis van informatie over Dynamic Logical Partioning op de website van IBM, http://www.ibm.com/servers/eserver/iseries/lpar, 2005. 4 Instructies die door het besturingssysteem aan de hardware worden gegeven om bepaalde taken uit te voeren, zoals het openen van een bestand op de harde schijf of het uitvoeren van berekeningen 5 Op basis van informatie over Dynamic Logical Partioning op de website van IBM, http://www.ibm.com/servers/eserver/iseries/lpar, 2005. 6 Op basis van informatie over vPlatform op de website van VMware,’vPlatform’, http://www.vmware.com/products/ vplatform, 2005. 7 Op basis van informatie over Microsoft Virtual Server 2005 op de website van Microsoft, http://www.microsoft.com/ windowsserversystem/virtualserver/default.mspx, september 2004. 8 Op basis van informatie over HP-UX11i op de website HP, ‘HP Virtual Server Enviornment for HP-UX 11i and multiOS’, http://h71028.www7.hp/com/enterprise/cache10381-00-0-121.aspx, 2005.

Tot slot ‘Virtualisatie is het gebruik van software om hardware of een gehele computeromgeving anders dan die waar de software feitelijk op draait, te emuleren11’. Na deze definitie is in dit artikel ingegaan op de achtergrond van virtualisatie, is de werking uitgelegd, zijn de voor- en nadelen op een rijtje gezet, en is de invloed van virtualisatie op het werk van de IT-auditor behandeld. Virtualisatie is tegenwoordig beschikbaar voor vrijwel

9 Op basis van informatie over Sun Solaris op de website van Sun, ‘Solaris 10 Utilization’, http://www.sun.com/software/solaris/utilization.jsp. 10 Op basis van informatie over Galaxy op de website van HP, ‘OpenVMS Galaxy’, http://h71000.www7.jp.com/availability/galaxy.htm, 2005. 11 Deze definitie is uit het Engels vertaald op basis van de definitie op SearchStorage.com onder ‘virtualization’, http://www.searchstorage.com, juni 2005.

43

44


Interview IT-auditor: adviseur of controleur? Het profiel van de auditor behoeft verduidelijking. Als een CIO een IT-auditor inschakelt, zoekt hij meer een adviseur dan een controleur. Een accountant daarentegen schakelt eerder een IT-auditor in als controleur. Kortom: is de IT-auditor nu vooral een accountant op IT-gebied of een IT-consultant met auditkennis. Het profiel behoeft verduidelijking en de klantvraag zou daarbij centraal gesteld moeten worden. Dit stelt Prof. dr. R(ob) G.A. Fijneman RE RA in z’n oratie ‘IT-auditing: grenzeloos of gelimiteerd’, uitgesproken op 22 april 2005 aan de Universiteit van Tilburg bij de aanvaarding van het ambt van hoogleraar EDP-auditing. Van deze oratie is ook een bewerking gepubliceerd in Automatisering Gids van 6 mei 2005. Interview door Wilfried Olthof en Rainer Steger

We leggen enkele stellingen en conclusies van Rob Fijneman voor aan collega-hoogleraar Prof. Drs. P(aul) L.A.M. van Kessel RE RA, eveneens verbonden aan de Universiteit van Tilburg en evenals Rob Fijneman partner bij één der ‘big four’-kantoren en voorzitter van EDPaudit aldaar.

beperkt bent in je adviesmogelijkheden. Dan ben je dus auditor en mag je geen advies doen! Wanneer je daarentegen niet optreedt als auditor, dan kun je best adviezen geven. Het is dan ook geen academische discussie die los van de maatschappelijke werkelijkheid kan worden gevoerd.’

Adviseur of controleur? Paul: ‘Rob Fijneman werpt de vraag op: ‘Wat is nu eigenlijk een IT-auditor?’ Is het een auditor of is het een consultant? Hij benadert die vraag vanuit de individuele beroepsbeoefenaar. Als je de vraag op die manier stelt, dan kom je er (dus) niet uit. Ik vind zelfs dat hij in deze tijd een hele gevaarlijke discussie begint, waarbij hij tegen de stroom in roeit. Het gaat niet zozeer om het één (audit) of het ander (advies), maar om het op verantwoorde wijze scheiden van audit en advies. Je kunt dus niet zomaar ‘out of the blue’ de vraag stellen: is de IT-auditor een auditor of consultant? Ik vind deze vraag op twee punten te breed.

Waait deze discussie over of

In de eerste plaats is het duidelijk dat sinds de boekhoudschandalen alle regelgeving – zoals de Sarbanes Oxley wet en de onafhankelijkheidrichtlijnen van de Security Exchange Commission (SEC) en het NIVRA – erop is gericht om ervoor te zorgen dat zodra je als individu of als organisatie bij een klant als auditor optreedt, je héél erg

Drs. W.J.A. Olthof is ambtelijk-secretaris van de NOREA;

moeten we hier iets mee? ‘De vraag is dus niet zozeer: ben ik nu een auditor of adviseur; waait deze hele discussie over of moeten we er iets mee? De markt heeft dat immers al voor ons bepaald. Wanneer je auditor bent, dan ben je geen adviseur en als je adviseur bent, dan ben je geen auditor. Volgens die praktijk acteren we ook in de maatschappen op grond van de aangescherpte onafhankelijkheidsregels. Dat was ook precies de aanleiding voor de accountancymaatschappen om de consultancytakken af te stoten. Dit wil overigens niet zeggen dat assurancebedrijven geen adviezen meer geven. Het gaat dus niet om het één of ander, het is beide maar met de beperking dat zodra je jezelf als auditor manifesteert, je géén adviseur (meer) bent. Het is geen vraag die je jezelf zomaar in het algemeen kunt stellen los van de maatschappelijke werkelijkheid. Je bent auditor en adviseur, maar waar je het één (audit) of het ander (advies) doet, wordt bepaald door de klant. Zodra je klant een ‘audit-klant’ is, dan kun je niet adviseren.’

Drs. R.J.Steger is Hoofd Adm. en Bedrijfsorganisatie van de KAS BANK, tevens redactielid van ‘de-EDP-Auditor’.

‘Ook in een ander opzicht wordt de discussie door Rob Fijneman te breed gevoerd. Dat betreft de vraag op welk


Paul van Kessel: ‘Een IT-auditor is niet primair een deskundige op het gebied van IT. Hij is een deskundige op het gebied van IT-controls.’ gebied de IT-auditor deskundig is. Neem de accountant als voorbeeld: de accountant is niet deskundig op bijvoorbeeld de inkoopprocessen of hypotheekprocessen, de betalingsprocessen of zorgprocessen. Zijn deskundigheid ligt op het terrein van de controls in en rondom die processen: internal-control en/of environmental-controls over die processen. Natuurlijk, als je heel vaak een inkoopproces hebt beoordeeld op het aspect control, dan weet je op een gegeven moment wel hoe een inkoopproces werkt. Maar onze ‘core-competence’ heeft te maken met control(s). Als ik naar de IT-auditor kijk, dan is een IT-auditor niet primair een deskundige op het gebied van IT. Hij is een deskundige op het gebied van IT-controls. En hoe je dus rondom die control(s) assurance kunt bieden.’

Een management consultant? Dat is ‘ie’ dus niet! ‘Wanneer je al de vraag stelt: is een IT-auditor een auditor of adviseur en je constateert: ja, bij sommige klanten is hij inderdaad een adviseur. Dan is hij dus een adviseur op het gebied van IT-control(s). En omdat hij vaker naar controlevraagstukken rondom IT heeft gekeken, weet hij veel van IT af. Maar het gaat veel te ver om – zoals Rob Fijneman doet – de indruk te wekken dat een IT-auditor zich ook nog als een all-round management-consultant op ITgebied kan manifesteren.

Soms zijn we consultant op het terrein van de controls van IT, maar dat is fundamenteel iets anders. Het behoort in principe niet tot het profiel van de IT-auditor om een pakketimplementatie te doen. Het behoort wel tot z’n competentie om te adviseren over de noodzakelijke application-controls die moeten worden ingebouwd in een pakket dat geïmplementeerd wordt.’ Moet het profiel van de auditor derhalve in de opleiding worden verduidelijkt? ‘Mijns inziens niet. Ook binnen de IT-audit-opleiding in Tilburg wordt altijd een bepaald aspect van IT inclusief de beheersing behandeld; vervolgens wordt aandacht besteed aan de wijze waarop de beheersingsaspecten kunnen worden geaudit. Het vertrekpunt van de audit-benadering is dus steeds het beheersingsvraagstuk: hoe stel je vast dat de onderneming dit stuk van de IT beheerst (in termen van betrouwbaarheid, beveiliging en continuïteit). Wanneer je dat als auditor doet, dan zit daar ook altijd een natuurlijke adviesfunctie aan, dat wil zeggen (daar is Rob Fijneman het blijkbaar ook mee eens) de auditor moet in staat zijn oplossingsrichtingen aan te geven. Maar dan houdt het – wat betreft de auditklanten – op. Je kunt natuurlijk alleen maar oplossingsrichtingen aangeven wanneer je weet hoe de beheersing van de IT in elkaar steekt. Wanneer je dus bij een andere organisatie komt waar je geen audit doet, dan kun je naar mijn mening best adviezen geven over de beheersing van IT. Het is eigenlijk een drieluik waarbij de

45

46


‘De IT-auditor zal zich in de toekomst moeten specialiseren, niet alleen inhoudelijk, maar ook qua werkveld.’ ‘knip’ zit tussen de natuurlijke adviesfunctie en de uitwerking van die adviezen. De beroepsorganisaties NIVRA en NOREA hebben zich terecht – vind ik – met name gericht op die audit-functie, want daar neem je als auditor verantwoordelijkheid voor je oordelen. Daar zijn die kwaliteitsregels, beroepsregels en ethische normen het meest belangrijk. Als het daarbij gaat over de financial-audit dan denk ik dat de IT-auditor gewoon meemoet in de regelgeving die geldt voor de financial-auditors, zeker wanneer hij RA RE is. Betreft het een RE (niet tevens RA), dan denk ik dat er missiven moeten zijn vanuit NOREA waarin staat: gij zult u houden aan hetgeen dat binnen de financial-audit gebruikelijk is. Wat dat dan precies is, dat zou naar mijn mening met spoed uitgewerkt moeten worden! Op dit gebied leven immers in de praktijk veel vraagstukken zoals scope afbakening, verantwoordelijkheid van de RE en rapporteren. Ik vind bovendien ook dat de NOREA zich druk moet maken over regels die in acht genomen moeten worden wanneer het een audit betreft die los staat van de financial audit. Als het gaat om advies (en accountants hebben ook veel geadviseerd; vroeger kon dat zelfs makkelijk bij auditklanten) hoef je daarover in aanvullende zin niet zoveel extra’s voor te regelen, want dan is er op grond van algemene beroepsregels en rapportagevoorschriften genoeg geregeld.’

Rob Fijneman roept op tot de ontwikkeling van een ‘common body of knowledge’ voor de IT-auditors. Over welke vaardigheden hoort de IT-auditor te beschikken en op welke wijze is dat te borgen? ‘Is het nodig dat een IT-auditor alles wat met beheersing van IT te maken heeft overziet? Nee, kijk maar naar de VU-opleiding; daar onderscheiden ze technical-auditors en system-auditors. Dat is al een inperking of specialisatie. Er zijn bijvoorbeeld ook proces-auditors, meestal oorspronkelijk RA’s die tevens de RE-opleiding zijn gaan doen. Die gaan op een andere manier met een onderzoek om en bereiken andere conclusies dan IT-auditors die geen proces-achtergrond hebben. Hoe breed moet je kennis zijn? Dat is een moeilijk te beantwoorden vraag.’

Accountants hebben er ruim honderd jaar over gedaan Een IT-auditor moet zich beperken tot de IT-componenten en rapporteren aan de directie. Moet hij z’n bevindingen in het business-perspectief kunnen plaatsen? ‘Hoe lang is het geleden dat de accountant in z’n managementletter opschreef dat de tweede handtekening op de


kassa-uitbetaling ontbrak? Het duurt vrij lang voordat je als collectieve beroepsgroep duidelijk kunt maken dat er belangrijkere dingen zijn dan het ontbreken van een specifieke controle. Het duurt even voordat iedereen het businessperspectief aan zijn specialisatie kan toevoegen en kan denken vanuit riskmanagement of business-controls. Het heeft pas toegevoegde waarde wanneer je in staat bent om het in een bredere context te plaatsen. De accountants hebben daar ruim honderd jaar over gedaan. Dan kun je van IT-auditors niet verwachten dat ze dat in no-time hebben bereikt. Naast diversiteit en specialisatie blijft het een belangrijke vaardigheid om als auditor goed te kunnen vaststellen of er sprake is van een rationele opdracht. De NOREA stelt in haar richtlijnen vast dat je als auditor moet beoordelen of er sprake is van een rationele opdracht alvorens de opdracht te aanvaarden. Daar hebben we een heel belangrijk punt te pakken. Alleen rationele opdrachten uitvoeren! Je moet voldoende materiekennis hebben maar ook en vooral de kennis om te beoordelen of er sprake is van een rationele opdracht. We kunnen allemaal een Unix-box onderzoeken en daaraan tot sint-juttemis risico’s onderkennen. Maar de kunst is om de scope van dit onderzoek en de diepgang van de risicoanalyse zodanig af te bakenen dat – in de context van de organisatie en de specifieke problematiek die daar speelt – gesproken kan worden van een rationele opdracht.’ Over welke vaardigheden dient een IT-auditor te beschikken? ‘Ik zou zo niet uit de losse pols kunnen beantwoorden hoe breed of diep de ‘skills’ van een IT-auditor zouden moeten zijn. Je zult kennis moeten hebben van processen en BIV/ AO. Verder moet je kennis hebben van COSO en ERM. De opleidingen bieden voldoende diepgang op de ITbeheersingsgebieden. Wat we in de praktijk missen dat zijn de mensen die kunnen denken vanuit architecturen en infrastructuren, IT-govenance en high-level-design van security-systemen. Waar hang je dat op in de organisatie, wie is verantwoordelijk, et cetera. Toch hebben we het qua opleidingsniveau en beroepskwalificatie met betrekking tot de IT-audit in Nederland prima voor elkaar, in vergelijking met andere landen. Maar adel verplicht. We moeten ons derhalve ook blijven conformeren aan de internationale normen voor de studiebelasting op academisch en (post-)master niveau. Naast kennis zijn ook (audit-)vaardigheden van belang. Hoe is het gesteld met de communicatieve vaardigheden, kennisonderhoud (‘leren- leren’)? De uitgangspunten in dat verband moeten worden vastge-

legd in de vereiste eindtermen en/of beschrijving van het noodzakelijke curriculum’. Is er ook een behoefte aan fundamenteel wetenschappelijk of toegepast onderzoek ten behoeve van dit vakgebied? Rob Fijneman noemt in dat verband de behoefte aan onderzoek op het gebied van audit-theorie en onderzoek naar de ethiek van de auditor. ‘Dat zijn op zich relevante thema’s. Maar zelf zou ik liever toegepast onderzoek zien. Bijvoorbeeld uitgebreide casestudies naar de inrichting van IT-governance in vijf of tien grote ondernemingen. Een beoordeling en vergelijking van de wijze waarop de IT-governance structuur is ingericht. Ik zou ook wel bij een X-aantal grote bedrijven onderzoek willen doen door met de CIO’s in kaart te brengen welke IT-audits in de afgelopen vijf jaar zijn uitgevoerd en dan aan de hand van een ‘rating-model’ proberen de meest waardevolle audit-opdrachten te achterhalen. Dan ontstaat er een beeld of we als beroepsgroep voldoende toegevoegde waarde leveren. We hebben niet echt een ‘track-record’ en een beeld over de mate waarin de ITaudit door de CIO wordt gewaardeerd. Ten slotte zou ik ook graag onderzoek doen naar de wijze waarop IT-auditors hun onderzoeken gericht op de beheersing van IT kunnen ondersteunen met data-analyses.’ Hoe ziet de toekomst van het vakgebied er uit? ‘Als je ziet wat er allemaal met IT gebeurt in organisaties! Meer en meer wordt alles in een organisatie bepaald door de IT. Dat noopt tot de reeds genoemde specialisaties. Naast de IT-auditor met een eigen opdracht zien we ook steeds vaker de IT-auditor samenwerken met andere assurance-providers (bijvoorbeeld financial-auditors, interne auditors). Deze samenwerking verloopt niet bepaald vlekkeloos. Als ze al samenwerken dan weten ze niet wat ze met de uitkomsten van elkaars werk moeten doen. Ook op andere gebieden (management control, treasury, cashmanagement) kun je niets meer aanpakken zonder IT in je vingers te hebben. Ook forensic-onderzoek is doordrongen van IT en techniek. De diversiteit wordt groter en groter. De toekomst is dus: specialisatie en leren optreden in multidisciplinaire teams. Een IT-auditor kan niet samenwerken met een financial auditor, operational auditor of forensic expert wanneer hij/zij niet begrijpt wat een financial auditor, operational auditor of forensic expert is, wat het werkterrein is, wat de werkmethode is, wat het begrippenkader is, et cetera. De IT-auditor zal zich derhalve moeten specialiseren: dat geldt niet alleen inhoudelijk (technisch, of proces/systeemgericht), maar ook qua werkveld (wil ik later zelfstandige opdrachten uitvoeren of met specialiseren in een bepaalde vorm van samenwerking).’

47

48


Reactie Rob Fijneman Uiteraard hebben we de reactie van Rob Fijneman op het voorgaande interview met Paul van Kessel opgetekend.

Interview door Wilfried Olthof en Rainer Steger

Rob opent het gesprek door aan te geven dat ‘Het dilemma adviseur of controleur’ in het artikel in Automatisering Gids enigszins is aangescherpt ten opzichte van zijn oratietekst. Daarin is het in een bredere context neergezet. Rob stelt: ‘Wat ik heb beoogd met de oratie is het schetsen van de ontwikkeling van het vakgebied vanuit het auditen accountantsprofiel. Vooral in de jaren negentig was binnen het vakgebied een steeds grotere adviescomponent te onderscheiden. Dat vertaalde zich ook in de instroom van medewerkers die als projectmanager naar IT-adviesopdrachten op zoek waren. Dat ging bijvoorbeeld over investeringsbeslissingen, pakketkeuzes, implementatietrajecten, et cetera. Begin 2000 zijn we vervolgens ook (als uitvloeisel van discussies in het accountantsberoep) voor de vraag gesteld: ‘waar staat de IT-auditor nu primair voor opgesteld?’ Je zou kunnen verwachten dat we dezelfde conclusie(s) zouden bereiken als de accountants, namelijk om je vooral op de attestfunctie te richten. Wat ik heb willen oproepen is de vraag: weten we nu zelf goed wat de afbakening zou moeten zijn en welke competenties horen daarbij? Dit geldt zowel van binnenuit (de individuele beroepsbeoefenaren en de beroepsvereniging) maar ook vanuit onze omgeving (de klanten). De vraag is of IT-auditors dat zelf bepalen of dat de opdrachtgevers feitelijk de keuze bepalen. In dat opzicht ben ik het ook wel met Paul van Kessel eens: het is niet het individu dat dat elke keer bepaalt, maar eerder de omgeving.’ Rob gaat in op de vaardigheden van een IT-auditor. ‘Ik heb (en nu generaliseer ik bewust enigszins) het idee dat een deel van de beroepsgroep in de jaren negentig op onderdelen behoorlijk ver is afgedwaald van het auditingvakgebied. Door omstandigheden worden we teruggebracht naar de ‘basics’: IT en auditing. Van daaruit ben je sterk in de adviserende rol. Wat we voor opdrachtgevers

precies meebrengen als toegevoegde waarde kunnen we echter niet altijd kort en bondig uitleggen. Kijk bijvoorbeeld naar de factsheets waarin we onze expertise proberen uit te leggen. Ik ben het met de opmerking eens dat onze kerncompetentie ligt bij IT-beheersing. Ook ben ik het met Paul eens dat we niet elke dag in vrijheid kunnen besluiten of we een audit- of adviesrol vervullen. Het aardige van het beroep is dat je bij verschillende klanten wel in verschillende rollen kunt optreden. In de praktijk ontstaat natuurlijk gaandeweg wel het onderscheid tussen ‘auditklanten’ en ‘non-auditklanten’. Ik heb echter wel het idee dat een IT-auditor bij non-auditklanten rondom ITbeheersing het nodige kan betekenen en juist daar in een adviesrol. Ik zou dus ook niet willen dat een IT-auditor alleen in een auditprofiel wordt neergezet. Uiteraard vergt de rolopvatting dat deze adequaat wordt ondersteund met Gedragsregels en Richtlijnen, een belangrijke taak voor de beroepsorganisatie. Wanneer je je op geen enkel moment meer met auditing-vraagstukken bezighoudt, dan is wel de vraag of je niet te ver afdwaalt van waar je in de kern bent opgeleid. De kerncompetenties moeten zorgvuldig worden onderhouden maar ook onderscheiden. We zijn dus (inderdaad) ook geen all-round consultants, maar wellicht hebben we ons in het verleden ook bewust niet al te nadrukkelijk tegen dat beeld verzet, toen ons dat nog goed uitkwam.’

Laten we als beroepsgroep proberen meer in de terminologie van onze opdrachtgevers te spreken

Hoe moet het nu verder met de IT-auditing-opleidingen? ‘In het kader van de IT-auditing-opleiding pleit ik ervoor om met studenten veelvuldig de discussie te voeren of een


vandaag op morgen, ook in de accountantspraktijk is daar lang over gedaan. Het is van belang dat men in de opleiding leert om de samenhang te ontdekken. Het ontwikkelen van de vaardigheden die daarbij horen krijg je niet in het bestek van een post-doctorale opleiding overgedragen. Daar is een langere combinatie van opleiding en ervaring voor nodig. Je kunt ook niet alles in die twee jaar opleiding stoppen.’

Rob Fijneman bepaald type opdracht past in het profiel van de IT-auditor. Hoe zit het met de ethische afwegingen? In dat opzicht hebben we als opleidingen en als beroepsorganisatie nog een slag te maken. Dat is ook een van de gebieden of thema’s waar ik meer onderzoek naar zou willen doen. Met betrekking tot de ‘common body of knowlegde’ ben ik er een sterk voorstander van om – zo lang dat kan – te werken met een generalistisch profiel. Een breed opgeleide IT-auditor, aangezien een behoorlijk aantal van de basisvaardigheden gelijk zijn, los van de verscheidenheid aan IT-omgevingen (applicaties en technische componenten). Een onderscheid in profiel wordt in de Tilburgse IT-opleiding ook niet gemaakt, de brede basis is en blijft een goed vertrekpunt. Het ontwikkelen van een profiel gaat niet van

‘Ten slotte: de belangrijkste boodschap van mijn oratie is: laten we als beroepsgroep proberen meer in de terminologie van onze opdrachtgevers te spreken en antwoorden te geven en niet zozeer vanuit de producten en oplossingen die door de IT-auditors van binnenuit worden bedacht. Hierbij speelt de wijze van rapportering een belangrijke rol. Opdrachtgevers stellen vaak betrekkelijk eenvoudige vragen zoals ‘kan ik die leverancier vertrouwen?’ of ‘levert het me iets op als ik investeer?’ Onze vaktechniek en wijze van reageren zijn vaak erg ingewikkeld. Nieuwe aanscherpingen op riskmanagementgebied brengen ons potentieel nog verder van de opdrachtgever af. De formuleringen in onze rapporten (‘niet is gebleken dat, et cetera’) helpen ons niet echt in het vinden van aansluiting met de klant. Daarin ligt echter wel onze uitdaging. Met het steeds verder standaardiseren van formuleringen van rapportages, uitingen of mededelingen dachten we eenduidiger en beter naar de markt te opereren, maar dat gaat ons nu ook voor de voeten lopen.’ ‘Er ligt een mooie toekomst voor ons. De opleving door Sox en Tabaksblat is niet van tijdelijke aard. De behoefte aan oordeelsvorming en (begrijpelijke) IT-beheersingsadviezen zal duurzaam zijn.’

49

50


EEN DAG UIT HET LEVEN VAN

Arno Nuijten De dag die ik uitkies is iets spannender dan mijn doorsnee dag: een beetje zenuwachtig als ik opsta, maar als ik ’s avonds thuiskom ben ik toch dik tevreden. Het is een belangrijke dag in het project waarover ik de regie voer. En ’s avonds moet ik cursus geven aan een groep internal auditors bij dezelfde klant. Veel tijd om me zenuwachtig te maken heb ik niet als de wekker gaat. Als ik de ochtenddrukte tussen Heeze en Amsterdam wil voorblijven, heb ik geen tijd om langer te blijven liggen. Is die file nog ergens goed voor. Ik moet voor de cursus zoveel materiaal meenemen, dat de trein deze keer geen optie is. De ruim anderhalf uur in mijn bestelbusje gaan vlot en ontspannen, door de ‘hoge zit’ hou je goed overzicht en dat vind ik wel prettig. Het enige nadeel van zo’n busje is dat het niet ‘past’ bij mijn colbert en stropdas en dus het professionele imago van mij als ICT-auditor. Een motor zou nog kunnen, levert je een ‘vlot’ imago op van iemand die risico’s niet uit de weg gaat. Met een busje kun je natuurlijk niet bij je klant aankomen. Gewoon onopvallend de ondergrondse parkeergarage in en niemand ziet je…. Tegen acht uur probeer ik bij mijn klant onopvallend de parkeergarage in te glippen, wat niet helemaal lukt. De bewaking en enkele stratenmakers gebaren druk naar me of ik wel héél zeker weet dat ik het red onder de hoogte van 2 meter 5. ‘Tuurlijk,’ zeg ik, niet helemaal zeker van mijn zaak, om vervolgens me een weg te manoeuvreren door de parkeergarage. Met de sproeikoppen van de sprinklerinstallatie links en rechts van me ‘op ooghoogte’. Fijn zo’n overzicht. Waarom luister ik eigenlijk niet naar goedbedoelde adviezen, die me waarschuwen voor gevaren. Ze brachten me aan het twijfelen, maar terwijl ik uitstap, ben ik blij dat ik me niet van mijn stuk heb laten brengen en heb doorgezet. Voorlopig is het allemaal goed gegaan en vanavond zie ik wel verder. In de lift naar boven bedenk ik me, dat dit een aardig voorbeeld was van mijn onderzoek naar het inschatten van

Drs. Ing. A.L.P. Nuijten is werkzaam als zelfstandig auditor en consultant op het gebied van beheersing van IT en bedrijfsprocessen. Hij is tevens docent aan de Erasmus Universiteit. [email protected].

en beslissen over risico’s. Er is al heel wat onderzoek gedaan naar hoe mensen verkeersrisico’s en gezondheidsrisico’s inschatten (‘het overkomt een ander maar mij niet’) en beslissingen nemen (‘hoe veiliger mensen zich in hun auto voelen, hoe harder men geneigd is te rijden’). Objectieve informatie over feitelijke risico’s blijkt maar betrekkelijke invloed op de risicoperceptie en beslissingen van mensen te hebben. Als ICT-auditor zijn we de hele dag bezig met ICT-risico’s van projecten, beheer, systemen. Toch weten we maar bar weinig over risicoperceptie en beslissingen over ICT-risico’s. Aan de Erasmus Universiteit ben ik bezig met enkele experimenten en enquêtes over de perceptie van ICT-risico’s. Erg leuk, maar vandaag staat er iets anders op de agenda. Ik stap uit de lift. We hebben een bijeenkomst met een zogenoemde Reference-group van het project waar ik sinds driekwart jaar de projectleider van ben. Het project loopt al langer, maar was onderhevig aan ‘strubbelingen’ toen ik er in stapte. Er lag destijds weliswaar een prachtig projectplan waarin tot in detail alle projectstapjes, alle ‘te bedenken’ projectrisico’s en prachtig sluitende planning waren beschreven. Maar toch was het project niet vooruit te branden. Onder de project-’buitenkant’ bleek dat veel van de betrokkenen ‘geen vertrouwen’ in het project hadden. Om heel uiteenlopende redenen. De een vond de specificaties te globaal (‘de dagelijkse praktijk is veel ingewikkelder dan in de specificaties beschreven’). De ander vond het weer te gedetailleerd (‘want er zijn nog onduidelijkheden op de hoofdlijnen’). De een vond dat er te weinig rekening werd gehouden met ‘het verleden’ en de ander vond dat het project niet voldoende toekomstgericht was en veel te voorzichtig. De taak die ik als projectleider heb opgepakt, was er vooral op gericht om samen met de mensen in en rond het project met kleine maar zichtbare stappen progressie te boeken en daarmee de verschillende belanghebbende partijen ‘aan boord’ te krijgen. De vergadering met deze reference groep verloopt naar tevredenheid. Weer een stapje vooruit. Op deze manier proberen we als een olievlek het draagvlak onder het project te vergroten, zodat de diverse business units in de 45 landen zich ook daadwerkelijk aan de nieuwe werkwijze en het nieuwe systeem gaat conformeren. Een transformatie door middel van een nieuw informatiesysteem in een politieke omgeving. Als ik als ICT-auditor mijn eigen project moest beoordelen, had ik


wat inkoppertjes zoals ‘end-user involvement’, ‘governance’ en formele vastleggingen. Als projectleider zit ik op een andere stoel en merk ik wat het vergt om zélf een project op de rails te krijgen, hoe moeilijk het is om ‘de neuzen dezelfde kant op te krijgen’ en hoe blij je mag zijn met een stuurgroep die achter je staat. En dat het (zéker voor een ICT-auditor als ik) een kunst is de positieve kanten van je project aandacht te geven om mensen te motiveren, zonder natuurlijk de projectrisico’s uit het oog te verliezen. Softe taal voor een (ICT-)auditor, harde werkelijkheid voor een projectleider. ’s Middags ontvang ik het rapport over de security-test (onder andere penetratietest) op de preproductieversie van ons nieuwe systeem, uitgevoerd door een externe partij. Irritant is het dat ze enkele beveiligingslekken rapporteren, die we hun zelf verteld hebben (en die nog opgelost worden voor we in productie gaan). Eigenlijk voel ik me (als ervaren ICT-auditor) in mijn wiek geschoten en heb de neiging om van me af te bijten. Het zou me weinig moeite kosten om ‘gaten’ in hun rapport te schieten. Ik realiseer me dat projectleiders zich vaak zo voelen als ze ‘van de zijlijn’ kritiek krijgen, bijvoorbeeld in een auditrapport. Eigenlijk vreemd dat je als ‘auditor’ allergisch reageert als je zélf een keer formeel bekritiseerd wordt. Ik bereid me vervolgens voor op de training die ik de rest van de dag en avond verzorg voor medewerkers van de interne accountantsdiensten van twee financiële instellingen: CIA-training. Bij het langslopen van de sheets en het oefenmateriaal valt me op dat in de lesstof naast de zogenaamde preventieve, detectieve en correctieve controls (ons allemaal bekend) een categorie ‘directive controls’ is toegevoegd. De eerste drie gericht op risico’s, de laatste gericht op doelen en behalen van succes. Vreemd dat me dat nooit eerder was opgevallen in een jaar of vijftien ICT-audit. De CIA-training loopt goed. Veel interactie. Ik word een beetje onrustig als het onderwerp ‘sprinklerinstallaties’ voorbij komt. Het voordeel van een drypipe-sprinklerinstallatie: geen douche/stortvloed als onverhoopt een leiding springt of wordt beschadigd. Quasi geïnteresseerd vraag ik of de parkeergarage zo’n fool- en accidentproof sprinklerinstallatie heeft. Om half acht is het mooi geweest en zonder problemen ben ik anderhalf uur later weer thuis. Het was een nuttige en enerverende dag. Morgen heb ik een cursus die niets en tegelijk alles te maken heeft met mijn werk als projectleider, ICT-auditor en onderzoeker. De vierde dag van een twaalfdaagse certi-

ficatiecursus over gedragsstijlen van mensen en hoe je dat kunt meten en analyseren. Mijn medecursisten zijn allemaal ‘teambuilder’, changemanager, personal coach of therapeut. Ik ben een buitenbeentje in dit gezelschap. Ik heb maar gezegd dat ik projectleider, interim-manager, consultant ben. ICT-auditor heb ik niet uitgelegd. De vorige les is een aantal gedragsstijlen toegelicht, wat nogal wat herkenning bij me opriep: neig je naar details of liever naar hoofdlijnen; neig je naar het voorkomen van problemen of naar bereiken van doelen; denk je in acties, of in informatie of in mensen. Het grappige is dat je op deze manier iemands voorkeurgedrag op dertien dimensies kunt meten en daarmee heel aardig kunt analyseren wat voor problemen dit zou kunnen veroorzaken bij de invulling van een bepaalde rol of in de samenwerking binnen een team. Het allermeest trof me het volgende voorbeeld: Als je een nieuwe TV koopt en je vindt het prettig om de stappen in de installatiehandleiding langs te lopen, dan neig je naar ‘procedurele’ gedragsstijl. Als je geneigd bent om het apparaat direct aan te sluiten en kriskras alle knoppen en mogelijkheden uit te proberen, neig je naar ‘optionele’ gedragsstijl. Niks goed of fout aan, gewoon een voorkeursstijl die je soms van pas komt en soms tot last is. De docent (psycholoog) geeft een voorbeeld: iemand die ‘optioneel’ denkt is veelal heel goed in het analyseren, beoordelen van processen en procedures die hij/zij van allerlei kanten belicht. Maar zo iemand heeft soms moeite om deze kwaliteit uit te schakelen en heeft er wellicht moeite mee om simpelweg een stappenplan, een procedure van begin naar eind uit te voeren, zonder hem ter discussie te stellen. De kritische, analytische ICT-auditor die heel goed is in het beoordelen van plannen, processen en projecten is dus niet automatisch (en misschien zelfs juist wat minder) geneigd en sterk om dat plan, proces, project (of controleprogramma) ook daadwerkelijk gestructureerd, stapsgewijs van begin naar eind uit te voeren (zonder het te blijven analyseren, bij te stellen enzovoorts). Leuk om je eigen scores op die dertien dimensies in een schema te zien. Bladerend door het studiemateriaal kom ik bij de voorkeurstijl of je geneigd bent te kijken naar verschillen of juist naar overeenkomsten. Het voorbeeld gaf me de oplossing voor mijn ‘bestelbusjes-imago’: eigenlijk heeft hij ontzettend veel weg van een Lamborghini, met wat extra bagageruimte en grijs kenteken…

51

52


Automatiseringsbedrijf wint tuchtprocedure tegen RE RA Partijen in het geding: 1. Een automatiseringsbedrijf (hierna te noemen AUT, staand voor een bedrijf dat softwarepakket ERP heeft verkocht). 2. Een bedrijf (hierna te noemen TRADE) dat in 1997 een overeenkomst sloot met AUT om pakket ERP Kor Mollema bij TRADE te installeren. 3. EDP-Auditor, tevens Accountant (hierna te noemen RERA) die het pakket in opdracht heeft beoordeeld.

Chronologie van feiten: 1997, juli: TRADE sluit met AUT een overeenkomst tot het installeren van ERP bij TRADE. 2000, maart: Na klagen van TRADE over uitblijven oplevering ERP worden daarover concrete afspraken gemaakt. Onderdeel daarvan is beoordeling van het geïmplementeerde ERP door een extern deskundige en de aanstelling van een projectmanager. Kosten te vergoeden door AUT, tot een maximum van 10.000 gulden. 2000, juli: TRADE geeft aan RERA de opdracht om de bedrijfsprocessen en informatievoorziening zoals ondersteund door ERP te evalueren. 2000, oktober: RERA brengt zijn rapport uit aan TRADE. Hij heeft ten aanzien van zijn conclusies geen hoor en wederhoor toegepast op de maker van ERP, nl. AUT. De conclusies zijn: • ERP ondersteunt onvoldoende de bedrijfsprocessen van TRADE. • De betrouwbaarheid van de gegevensverwerking is niet in overeenstemming met eisen die hieraan moeten worden gesteld. • Indien TRADE vasthoudt aan overgang naar de euro per 1 januari 2001, dan is de continuïteit van de gegevensverwerking in onvoldoende mate gewaarborgd. RERA besluit met het aanbod om een aantal concrete aanbe-

Prof. Dr. Kornelis Mollema RE RA is parttime hoogleraar bij de postdoctorale EDP-Auditopleiding aan de Erasmus Universiteit.

velingen te doen voor het doorvoeren van verbeteringen gedurende de periode dat nog met ERP moet worden gewerkt. (Kennelijk heeft TRADE al besloten te kappen met ERP.) 2000, oktober: De advocaat van TRADE stelt AUT in gebreke op basis van het rapport van RERA, waarvan kopie wordt bijgevoegd. 2001, juli: Inmiddels heeft AUT aan RERA de opdracht gegeven een onderzoek ‘verbeteringen software’ (lees ERP) uit te voeren, waarvan in juli 2001 rapport wordt uitgebracht. Strekking: in opzet voldoet ERP aan daarvoor overeengekomen normen, maar de juiste werking hangt sterk af van de implementatieomgeving. RERA zegt niet te hebben geweten dat deze opdracht een conflict of interest inhield, voortkomend uit het feit dan AUT en TRADE inmiddels in een civiele procedure waren verwikkeld. 2001, september: Het wordt RERA duidelijk dat AUT zijn rapport van juli 2001 wil gebruiken in de civiele procedure tegen TRADE. RERA beëindigt het conflict of interest door zijn relatie met AUT te verbreken. 2003, januari: AUT dient een klacht in bij de Raad van Tucht voor Registeraccountants (RvTRA) tegen RERA. 2003, juli: AUT dient een klacht in tegen RERA bij de Raad van Tucht voor Register EDP-Auditors (RvTRE). 2003, oktober: De RvTRA komt tot een beslissing. 2003, december: AUT gaat tegen de beslissing van de RvTRA in beroep bij het College van Beroep voor het Bedrijfsleven (CvBB). 2004, februari: RvTRE komt tot een beslissing. 2004, december: Het CvBB komt tot een beslissing.

Aard van de casus De aard van de casus is er een van dertien in een dozijn, al zijn er nog niet veel die een tuchtprocedure tegen een RE hebben uitgelokt: een conflict tussen de leverancier en de koper van software (ERP) over de tijdigheid en kwali-


teit van implementatie door de leverancier. Deze en dergelijke ruzies worden uitgevochten in civiele procedures. Het belang van een additionele tuchtprocedure hierin is onder andere dat de conclusies van de Raad van Tucht kunnen worden gebruikt in genoemde civiele procedure. De klacht van AUT tegen RERA bij de RvTRA omvat de volgende essentiële elementen: • onzorgvuldigheid in rapportering door het niet toepassen van hoor en wederhoor; • foute conclusies; • schending van vertrouwelijkheid van correspondentie; • valsheid in geschrifte; • geen onpartijdigheid in het oordeel. Het bijzondere van de casus is viervoudig: • De betrokken EDP-Auditor is RE en RA en wordt daardoor in een tuchtprocedure betrokken bij zowel de RvTRA als de RvTRE, en in tweede instantie ook nog bij het CvBB. • Hoor en wederhoor moeten ruim worden toegepast. • De RERA raakt verstrikt in een conflict of interest voor wat betreft twee van zijn klanten die beiden van zijn inzicht gebruik willen maken om een juridisch geschil dat zij met elkaar hebben te winnen. • Het feit dat de RERA fouten heeft gemaakt, toont nog niet aan dat hem een verwijt van gebrek aan objectiviteit kan worden verweten. • Het oordeel van het CvBB wijkt aanzienlijk af van dat van de RvTRA.

De dubbele procedure Beroepsbeoefenaren die beide titels voeren ondertekenen hun rapporten en correspondentie niet ongebruikelijk met beide titels. Het blijkt dat deze chique ondertekening de weg opent voor een tuchtprocedure bij zowel de RvTRA als bij de RvTRE. Bij de RvTRA komt vervolgens de vraag aan de orde welke regiem van toepassing is, optredend als accountant of als openbaar accountant. Het simpele feit dat het hier om een EDP-audit gaat, sluit volgens het CvBB niet uit dat het om een onderzoek door een RA gaat. Het feit dat RERA als RE werkt in een organisatie die nauw gelieerd is aan een gelijknamig accountantskantoor (blijkens bijvoorbeeld zijn briefpapier) en ook nog steeds jaarrekeningen in de kwalificatie van RA ondertekent, is voor de CvBB voldoende grond om hem ook nog aan te duiden als optredend als openbaar accountant, wat betekent dat het zwaarste regiem aan gedrags- en beroepsregels van toepassing is. Beroepsbeoefenaren die naast de titel RE ook die van RA voeren, moeten nog maar eens nadenken of daartussen niet een wat strengere separatie moet worden aangebracht.

In ons rechtssysteem geldt als basisprincipe ‘ne bis in idem’ (geen tweemaal in dezelfde zaak), wat zoveel betekent als dat je niet voor één zaak tweemaal kunt terechtstaan. Recht toe recht aan toegepast zou dat betekenen dat een klager niet een tuchtprocedure kan aanspannen bij zowel de RvTRA als de RvTRE. In het onderhavige geval heeft echter de RvTRA gesteld niet deskundig te zijn op de inhoudelijke EDP-aspecten. Zij heeft klager (in casu AUT) geadviseerd daarvoor een procedure aan te spannen bij de RvTRE, een advies dat AUT heeft opgevolgd. De consequentie is dat bij de RvTRA de klacht in eerste instantie werd behandeld zonder de inhoudelijke EDPaspecten en dat bij de RvTRE in een latere procedure uitsluitend deze aspecten zijn behandeld. Hierdoor zou geen inbreuk ontstaan op het ‘ne bis in idem’. Een dergelijke splitsing van de zaak is echter gekunsteld, zoals ook blijkt. Over één twistpunt, nl. euroconversie heeft de RvTRA een uitspraak gedaan. Omdat het hier gaat om toetsing aan een van de overeengekomen EDP-normen, ontkomt ook de RvTRE niet aan een oordeel. Het ‘ne bis in idem’ dwingt haar nu te verwijzen naar de beslissing in dezen reeds genomen door de RvTRA. De RvTRE stemt met die beslissing in, maar stel dat dit niet het geval geweest zou zijn? Dat zou geleid hebben tot een vreemde patstelling. Blijft de vraag openstaan waarom de RvTRA geen gebruik heeft gemaakt van externe deskundigen voor wat betreft de EDP-aspecten. Dat is een begaanbare route en zou hebben voorkomen dat de behandeling van de zaak nu een onnatuurlijke splitsing krijgt. In de gekozen route wordt één en dezelfde zaak behandeld voor twee raden van tucht met langs de RA-zijde de mogelijkheid van beroep bij het CvBB. Een omslachtige weg. De RvTRE had dit ook kunnen overwegen en de deelklacht niet ontvankelijk kunnen verklaren met terugverwijzing naar de RvTRA. Eigenaardig is ook dat het CvBB over de vraag of tegen een RA, tevens RE zijnde in dezelfde zaak bij zowel de RvTRA als de RvTRE een procedure kan worden aangespannen geen algemene uitspraak heeft willen doen, omdat artikel 52 van de wet RA daarvoor geen ruimte zou bieden.

Hoor en wederhoor Nadat RERA de bedrijfsprocessen en informatievoorziening zoals ondersteund door ERP bij TRADE heeft bestudeerd, brengt hij daarover in oktober 2000 aan TRADE rapport uit. De conclusies zijn negatief (zie chronologie). RERA heeft evenwel voor het uitbrengen van zijn rapport geen hoor en wederhoor toegepast bij AUT. Zijn motivatie om dit niet te doen was dat hij niet het pakket als zodanig beoordeelde, maar de bedrijfsprocessen en informatievoorziening bij TRADE zoals ondersteund door ERP. De

53

54


RvTRA volgt RERA in deze redenering. Het CvBB is van oordeel dat hoor en wederhoor door RERA bij AUT wel degelijk had gemoeten. Het college is van mening dat, met name gezien de negatieve bevindingen ten aanzien van de softwareondersteuning door ERP, RERA gehouden was hoor en wederhoor bij de leverancier toe te passen. Zij illustreert dit door te wijzen op een van de conclusies van RERA, namelijk het niet beschikbaar zijn van een conversietool. Navraag door RERA bij AUT had helder gemaakt dat dit tool wel bestond en op eerste aanvraag beschikbaar had kunnen komen. Indirect ‘overruled’ deze zienswijze ook het oordeel van de RvTRE, die ten aanzien van het conversietool de RERA in zijn conclusie in het gelijk stelde, simpelweg omdat het tool misschien wel bestond maar bij TRADE niet geïmplementeerd was. De conclusie is helder. De RA die geïmplementeerde software beoordeelt, is gehouden om hoor en wederhoor toe te passen bij de leverancier, zeker in het geval dat de conclusies negatief zijn. Hoewel het CvBB geen beroepsinstantie is voor klachten tegen RE’s, moet toch worden aangenomen dat het standpunt van het CvBB de werking heeft van jurisprudentie, ook voor de RvTRE en daarmee voor alle RE’s. Dit heeft verstrekkende gevolgen voor de beroepsuitoefening van de EDP-auditor.

consequenties heeft in de procedure (omdat de klacht was dat RERA feitelijk op de hoogte zou zijn geweest), is zij wel van belang. Ze toont aan dat er bij RERA een zekere eigen verantwoordelijkheid ligt inzake dit geïnformeerd zijn. RERA had zich in zijn rapport aan TRADE negatief uitgelaten over ondersteuning door AUT en kon weten of vermoeden dat er onmin zou ontstaan tussen TRADE en AUT. Het aannemen van de opdracht van AUT had bij RERA een belletje moeten laten rinkelen. Conclusie: Als het gaat om conflict of interest zijn formaliteiten dunne pilaren om je achter te verschuilen.

Conflict of interest

Alles overziende moet worden vastgesteld dat de CvBB tot conclusies is gekomen die ongeveer haaks staan op die van de RvTRA. De RvTRA heeft RERA slechts een schriftelijke waarschuwing op een betrekkelijk gering onderdeel van de klacht, nl. op de formulering van RERA dat hij ERP in verbeterde versie niet zou hebben onderzocht, terwijl dit wel het geval was, zij het in laboratoriumopstelling. Voor het overige wordt de klacht verworpen. Het CvBB verklaart de klacht van AUT wel gegrond, behoudens op het onderdeel valsheid in geschrifte. Het vernietigt de tuchtbeslissing van de RvTRA. Het college acht zich bevoegd de zaak zelf af te doen en legt RERA de maatregel van schriftelijke berisping op. Het geeft te denken dat het CvBB tot zo’n ander oordeel komt dan de RvTRA. Als dit iets zegt over de kwaliteit van de tuchtrechtspraak is het een goede vraag bij welk rechtscollege men zich achter de oren moet krabben.

Nadat RERA zijn conclusies over ERP heeft gerapporteerd, vraagt AUT hem om een beoordeling van ERP in laboratoriumopstelling gericht op het adviseren van verbeteringen. Voor RERA een aantrekkelijke opdracht omdat hij immers al betrekkelijk veel kennis heeft van ERP. Ook kan hij gebruikmaken van het normenstelsel zoals gehanteerd bij de opdracht van TRADE aan RERA. In juli 2001 brengt hij zijn rapport uit aan AUT. Merkwaardig is dat RERA nu (in laboratoriumopstelling) tot een veel milder oordeel over het pakket komt. Wel maakt hij daarbij het voorbehoud dat veel afhangt van de implementatieomgeving. Na het uitbrengen van zijn rapport komt RERA erachter dat zijn rapport bedoeld is om gebruikt te worden in een inmiddels lopende civiele procedure tussen AUT en TRADE en krijgt hij vol zicht op het conflict of interest. Hij beëindigt zijn relatie met AUT en zet zijn relatie met TRADE voort. In de tuchtprocedure oordeelt de RvTRA dat RERA in het ontstane conflict of interest geen verwijt kan worden gemaakt. Immers, er is geen bewijs dat hij op de hoogte was van de civiele procedure tussen TRADE en AUT. Het CvBB volgt deze redenering, maar voegt in zijn overwegingen toe dat RERA wel op de hoogte had moeten zijn, omdat daarover inmiddels een mail bij een van zijn ondergeschikten lag. Hoewel deze overweging geen directe

Gebrek aan objectiviteit Het CvBB heeft geconstateerd dat RERA op een aantal punten onzorgvuldig heeft gehandeld, onder andere op het punt van geheimhouding (getoetst aan de GBR). Maar dat geeft volgens het college nog geen grond voor de beschuldiging dat de RERA niet objectief zou zijn. Hier lijkt het college ineens een mild oordeel te vellen. Immers, men zou ook kunnen verdedigen dat onzorgvuldigheid de schijn van gebrek aan objectiviteit kan oproepen.

Het oordeel van het CvBB kan aanzienlijk afwijken van dat van de RvT.

Deze samenvatting en annotatie is geschreven naar aanleiding van: • uitspraak 2004-1, NOREA Raad van Tucht, zie www. norea.nl onder ‘tuchtrechtspraak’; • uitspraak R 399 Raad van Tucht voor Accountants en Accountants-administratieconsulenten, zie www.nivra.nl; • uitspraak LJN: AR8309, College van beroep voor het bedrijfsleven, AWB 03/1491, zie www.rechtspraak.nl.


BOEKBESPREKING

Kracht van de vernieuwing; Visies op ICT Titel Auteur Uitgever ISBN

: Kracht van de vernieuwing; Visies op ICT : Dr. Abbas Shahim RE (red.) : Academic Service, in samenwerking met KPMG : 90 395 2332 0

Inleiding Het hier besproken boek bundelt de visies van dertien auteurs, die elk hun sporen op hun terrein hebben verdiend. De auteurs hebben hun inzichten overigens grotendeels ook al elders weergegeven. Het is een boek met een boeiende inhoud, dat vlot en pakkend geschreven is. De bundel is een KPMG-productie; acht van de bijdragen zijn geschreven door auteurs uit de KPMG-‘stal’. Wat ik met name waardeer is dat ICT-zaken op strategisch niveau worden aangesneden. Daarmee geeft het boek enige diepte aan de dagelijkse praktijk van de IT-auditing. Wie van ons heeft niet ervaren hoe lastig het is om een brug te slaan tussen het operationeel/technische niveau van de audit en het strategische niveau van de top van de organisatie? En die top is natuurlijk wel de eigenaar van de ICT die wij auditen. De visies die de revue passeren kunnen worden gegroepeerd in de volgende clusters: • Risicobeheersing • Outsourcing • Infrastructuur • Overig Omdat een beschrijving van alle artikelen teveel ruimte zou vragen zijn keuzen nodig. Ik beperk me tot de eerste twee clusters, maar dat is een puur persoonlijke selectie. Verder beschrijf ik uit het cluster ‘Overig’ één bijdra-

ge, namelijk die over IT-Governance omdat dit een tamelijk hot issue is.

Risicobeheersing Cees Coumou (‘Risicomanagement, verantwoord onzeker’) schetst een wijze van omgaan met risico’s die uit de volgende drie elementen bestaat: • vermijden van fundamentalisme; • transparante rapportage; • het gebruik van fronttroepen. Fundamentalisme: het gevaar bestaat dat een op risicoanalyse gebaseerde benadering van risicobeheersing ontaardt in een lawine aan analyses op te getailleerd niveau. Dit leidt vooral tot steeds meer stapels papier, die allerlei risico’s tot in detail beschrijven en niet zozeer tot een betere beheersing van die risico’s. Begin maar eerst met de belangrijkste risico’s aan te pakken op basis van een subjectieve risico-inschatting, zo redeneert Coumou. Deze aanpak is in elk geval aan de stakeholders uit te leggen, en de organisatie moet daar transparant in zijn. Transparante rapportage biedt de stakeholder de mogelijkheid een beeld te krijgen van het gevolgde proces en – om Coumou’s redenering af te maken – daar iets van te vinden. De fronttroepen, ten slotte, zijn de direct betrokken medewerkers. Zij kennen de dagelijkse praktijk – en daarmee ook de belangrijkste risico’s én zij vervullen een sleutelrol bij het

realiseren van beheersingsmaatregelen. Vervolgens wijst Coumou op de noodzaak om vanuit de bedrijfsvoering een visie op acceptabele risico’s te ontwikkelen, die uitmondt in doelen en prioriteiten voor beveiligingsmaatregelen. Deze doelen moeten meetbaar worden gemaakt met indicatoren. Het sluitstuk van risicobeheersing is de interne rapportage, eventueel ondersteund door externe oordelen, bijvoorbeeld in de vorm van certificering. De bijdrage van Paul Overbeek (‘Informatiebeveiliging: het tactisch niveau’), sluit hier goed op aan. Het tactische niveau zorgt ervoor dat het beleid (lees: de visie en doelen waar Coumou op doelt) op uniforme en consistente wijze wordt vertaald naar maatregelen en activiteiten op operationeel niveau. De functie Informatiebeveiliging, die Overbeek op tactisch niveau positioneert, zorgt hiertoe voor: • algemene hulpmiddelen: methoden, technieken, raamwerken, et cetera; • afstemming en coördinatie met het strategische en het tactische niveau en met functies die aan de informatiebeveiliging zijn gerelateerd; • procesaanjaging door de functie Informatiebeveiliging; • interne organisatie van de functie Informatiebeveiliging zelf.

Outsourcing Guus Delen ‘Succesfactoren voor outsourcing van ICT’ behandelt drie

55

56


succesfactoren, te weten een gezonde business case, ontvlechting van processen en het kunnen aansturen van een leverancier. Kern van de business case is dat deze duidelijk maakt welke voordelen men met de uitbesteding van welke processen wenst te behalen. Deze voordelen kunnen variëren van zuivere ICT-kostenbesparing tot het flexibeler maken van de organisatie, om die daarmee beter te positioneren in de netwerksamenleving. De business case speelt niet alleen een rol rond de besluitvorming over uitbesteding, maar vormt ook een belangrijk referentiedocument om de dienstverlening tegen te monitoren. Een goed beredeneerde ontvlechting van processen (wat wordt uitbesteed, wat blijft in huis) vereist dat de architectuur van de organisatie in kaart wordt gebracht op de niveaus organisatie, informatie, informatiesystemen en technologie/infrastructuur. Delen schetst een aanpak waarbij ‘sourceable units’ worden gedefinieerd op basis van een gedetailleerde analyse van de architectuur. De succesfactor ‘aansturen van een leverancier’ bespreekt Delen in termen van het INK-model. De organisatie moet op niveau IV van het 1 model functioneren wil men een externe partij kunnen aansturen, en dus succesvol kunnen outsourcen. Ronald Paans (‘Outsourcing en Sarbanes-Oxley’) behandelt de consequenties die de Sarbanes-Oxley wet (SOx) heeft voor outsourcing. Grotere dienstverleners werken met een Third Party Mededeling (TPM) – dat wil zeggen, een onafhankelijke auditor geeft één verklaring af ten behoeve van alle relevante klanten – om te voorkomen dat die klanten allemaal zelf komen auditen. Zo’n mededeling is doorgaans gericht op opzet en bestaan van maatregelen. Deze aanpak werkt bij SOx echter niet meer. Volgens deze wet moet het

senior management namelijk jaarlijks verantwoording afleggen over de effectiviteit van de internal controls. Het is dan nodig om, naast de opzet en het bestaan, ook de werking van maatregelen te toetsen. Daartoe kan gebruik worden gemaakt van audits die worden gerapporteerd volgens het 2 SAS-70 model . SAS 70 kent twee rapportagevormen. Type I is beperkt tot opzet en bestaan, terwijl Type II zich ook uitstrekt tot werking. In het kader van SOx is voor de toepassingen die relevant zijn voor de boekhouding en de managementrapportage een Type-II verklaring nodig. Een efficiënte aanpak voor de SAS70 rapportages bestaat eruit een Type-I verklaring af te geven voor de gehele breedte van de dienstverlening en daarnaast per klant Type-II verklaringen voor specifieke toepassingen en de onderliggende platformen. Ook Herman van Gils (‘De revival van de Third Party Mededeling (TPM)’) behandelt de TPM. Hij beschrijft het ontstaan ervan, de TPM nu en die in de nabije toekomst. Net als Paans legt ook Van Gils een relatie met SOx en SAS 70. Voorts signaleert hij een trend die zich begint af te tekenen onder druk van de roep om corporate- en IT-governance: ook het verantwoordelijk management van de uitbestedende organisatie is nu aan tafel aangeschoven. En daardoor is er een belangstelling bijgekomen, namelijk cost management. Hierbij wordt onder meer gedacht aan processen bij de serviceprovider die de juistheid en volledigheid van de doorbelastingen moeten garanderen. Van Gils voorziet daarom een ontwikkeling van verbreding van uitsluitend verantwoordingsrapportages over de beveiliging naar doelmatigheidsvragen en kostenbeheersing.

nance, en voor IT-audits in dat kader. Hij verwijst naar de NOREA-publicatie over IT-Governance, waarin geconstateerd wordt dat IT-auditors deels al werkzaam zijn op dit terrein. Wel worden aan dat werk nieuwe dimensies toegevoegd. Naast het beoordelen van operationele IT-beheerprocessen en ITcomponenten, betrokkenheid bij TPM’s en het toetsen ten behoeve van externe toezichthouders, ontstaan nieuwe werkzaamheden. Te denken valt aan het beoordelen van het hele raamwerk van IT-Governance, het toetsen van IT-Governance als onderdeel van Corporate Governance en het toetsen aan alle relevante weten regelgeving.

Tot slot Het boek heeft eigenlijk geen onderwerp maar gáát wel ergens over. Aardig is vooral dat een breed scala aan gezaghebbende visies in één bundel bijeen is gebracht. De bijdragen hebben een gemiddelde omvang van zo’n acht pagina’s, dus verwacht vooral grote lijnen en geen details; terecht, want het zijn visies. Het boek biedt inspirerend ‘leesvoer’, met name voor aankomend IT-auditors. Meer ervaren IT-auditors zullen naar mijn inschatting veel van de inhoud herkennen … en, wie weet, er mogelijkerwijs óók nog van kunnen leren. Thomas Wijsman

Drs. Th. Wijsman RE is audit manager/ IT-auditor bij de Algemene Rekenkamer.

Noten 1 Noot recensent: niveau IV (fase IV) is als volgt gedefinieerd: Samen met partners in de voortbrengingsketen wordt gestreefd naar een maximale, toegevoegde waarde. Per partner wordt bepaald wie het meest geschikt is om een bepaalde taak uit te voeren. Besturingssystemen worden met elkaar verbonden. Innovatie staat voorop.

IT-Governance Rob Fijneman (‘Beat IT or Control IT’) vraagt aandacht voor IT-Gover-

2 Zie ook het artikel van Suzanne Keijl ‘SAS 70 en SysTrust’, de EDP-Auditor, jrg. 11, 2002, nr. 3, pp. 38-44.


57

VAN DE NOREA

Mededelingen Internetpagina-bespreking Collega, Internet is zo langzamerhand niet meer weg te denken uit ons leven. We gebruiken het dagelijks – privé – om ons te informeren, te (ver)kopen, reizen te boeken et cetera. Maar we kunnen via internet ook steeds meer informatie vinden die nuttig is bij de uitoefening van ons audit-beroep. Informatie om bij te blijven in het vakgebied, informatie over leveranciers van ICT-producten en de producten zelf – hardware, software, nieuwe releases en hun specificaties – en wellicht nog meer. Dat heeft de Redactiecommissie van de EDP-Auditor op het idee gebracht om korte artikelen te gaan plaatsen waarin auditors vertellen op welke wijze zij gebruikmaken van de informatie die via internet te vinden is bij het doen van audits. Via deze mail hopen wij potentiële schrijvers te vinden die hun ervaring met hun collega’s willen delen. Wat wij op het oog hebben is het beste te vergelijken met de vaste rubriek ‘boekbespreking’. Door het plaatsen van een boekbespreking kunnen collega’s enerzijds op een efficiënte manier kennis nemen van wat er gepubliceerd is, maar het kan anderzijds ook een reden zijn om het boek zelf te gaan lezen omdat je ontdekt dat het iets is waar je je verder in wilt verdiepen. Dat hebben wij ook voor met de ‘internetpagina’-bespreking: vertel collega’s wat de informatie inhoudt, waarom en wanneer het in de audit van pas komt, hoe betrouwbaar de informatie is et cetera. Mocht je ervoor voelen een bijdrage te leveren, stuur dan een mailtje naar [email protected] om verdere afspraken te maken. Thea Gerritse

Seminar Informatiebeveiliging onder architectuur Op 13 September 2005 organiseert ITSMF in de Vereeniging te Nijmegen, samen met NOREA en de andere verenigingen uit het vakgebied Informatiebeveiliging, weer een seminar middag/avond Informatiebeveiliging. Dit seminar is de opvolger van het goed beoordeelde congres ‘Informatiebeveiliging’ uit 2004. In 2004 waren er ruim 180 bezoekers. Tijdens het seminar zal ook de uitreiking plaatsvinden van de Joop Bautz Award, de jaarlijkse onderscheiding voor professionals en potentials uit het vakgebied. Het seminarprogramma gaat niet in op de technische achterkant, maar stelt juist de strategische en organisatorische aspecten van informatiebeveiliging en de relatie met architectuur centraal. Het middag/avondprogramma zal focussen op Integrale beveiliging (waaronder ketenbeveiliging), Compliancy en

een track voor meer diepgaande inhoudelijke presentaties. Onderwerpen zijn onder andere (onder voorbehoud): • Informatiebeveiliging en architectuur • Tabaksblatt compleet voor beveiliging? • Compliancy in de zorg • Beveiliging van de logistieke keten • Integrale beveiliging • Integraal risicomanagement • New forensics Verder zullen enkele presentaties specifiek ingaan op vernieuwingen in de informatiebeveiliging, de zorg, de overheid en de industrie. Voor het volledige programma en informatie over aanmelding/inschrijving zie: www.ib.itsmf.nl

58


Activiteitenkalender NOREA: • 13 september 2005: seminar Informatiebeveiliging onder Architectuur, tevens uitreiking Joop Bautz Award (gezamenlijke activiteit met de beroepsorganisaties voor informatiebeveiliging en itSMF) in de Vereniging te Nijmegen • 23 en 24 november 2005: ‘Update on ICT & Control(e)’, NOREA/VERA-congres in NH Leeuwenhorst te Noordwijkerhout

• 15 december 2005, NOREA Algemene Vergadering en symposium najaar Zie voor actuele aankondigingen: www.norea.nl

Nieuwe leden Met ingang van 1 augustus 2005 ingeschreven in het register van gekwalificeerde IT-auditors RE’s: Drs. R.J.W.P. Bastiaansen Mw. Z. Bekdemir Ing. A.A. Bitter M.J. Butterhoff bc R.M.M. Damen RA Mw. L.A.M. Dekker CISA Mw. Drs. M. van Dijk Drs. J.H.K. Dronkert Mw. Drs. R. Habiboellah M.H.L. Hendriksen CISA Mw. Drs. E.P.M. van den Heuvel Mw. Drs. P.X. Hooijschuur Drs. M.M. van Hooven RA Ing. J.W.C. van der Horst Ir. T.P.G. Louis Drs. G.J.M. Martens Drs. M. Mol RI CISA Drs. Ing. M. Ransijn F.D. Schut Ing. M.P.J. Sleegers Drs. P.H.T. Slootmaker Drs. R. Tamrouti V.E. Toms Drs. G. Vierling Mw. Drs. M.C.E. van de Wal Mw. S. van der Werve G. Zwiers RO CIA CISA CCSA

Wilderveld 12 Wijenburg 185 Meertensweg 31 Leeuweriklaan 97 Vroegeling 19 Surinameplein 55 p5 Statensingel 155 D Herman Gorterstraat 9 B Aalscholverstraat 44 Heuvelweg 6 H.J.Ganzemanstraat 9 Postbus 283, PAC AA 2130 Nieuwestraat 25 1e Daalsedijk 198 Rijksstraatweg 83 Oratoriumstraat 26 I Rembrandtlaan 33 Hooiijzer 39 Torckstraat 24 Odradastraat 12 Dijkgraafstraat 49 St Hubertusstraat 11 Tegentesselaan 47 Stiemensvaart 60 Beemdhof 4 Meidoornweg 49 De Vleyen 65

Vleuten Amsterdam Gieterveen Bussum Grave Amsterdam Rotterdam Rotterdam Purmerend Belfeld Meteren Zaandam Strijen Utrecht Haarlem Apeldoorn Bergschenhoek Oostzaan Velp Eersel Delfgauw Nijmegen ’s-Gravenhage ’s-Gravenhage Heteren Schoorl Hoofddorp

INHOUDSOPGAVE. Van de redactie 3. Column: Mag het een beetje meer wezen? 4 Gert van der Pijl. Reactie op de column van Anton Tomas 6 Ad de Visser

Recommend Documents