Reconciliatie bij Service Oriented Architecture (SOA) Controle ‘around the computer’ met geautomatiseerde reconciliatie voor de f inanciële verslaglegging bij de implementatie van SOA bij banken bekeken vanuit een IT audit perspectief. AO/IC maatregelen General IT controls Reconciliatie applicatie Operationele applicaties
Financiële applicatie suite MA rapportage FA rapportage Grootboek
DWH
ETL/ Rules engine Ontvangstomgeving Message infrastructure Netwerk infrastructure Hardware infrastructure
C.J.A. Wever Studentnummer 9100111 Scriptiestudentnummer 703 VU Amsterdam Postdoctoraal IT audit Datum 2-6-2007 Versie 1.1 Definitief
Inhoudsopgave 1 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 3.5 4 4.1 4.2 4.3 4.4 4.5 5 5.1 5.2 5.3 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 8 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 I
Inleiding ......................................................................................................................3 Informatiearchitectuur bij banken met SOA ............................................................. 5 Service Oriented Architecture bij banken................................................................ 5 Applicatie architectuur met SOA ............................................................................ 5 Logische informatiearchitectuur financiële domein .................................................. 6 Technische SOA infrastructuur .............................................................................10 Reconciliatieproces voor financiële verslaglegging.................................................13 Inleiding ............................................................................................................13 Doelstelling reconciliatieproces.............................................................................14 Processtappen ....................................................................................................14 Reconciliatierapportages......................................................................................16 Functiescheiding binnen het reconciliatieproces .....................................................16 Wettelijk en theoretisch kader.................................................................................17 Inleiding ............................................................................................................17 Interpretatie FIRM voor SOA en reconciliatie .........................................................17 Interpretatie SOx voor SOA en reconciliatie...........................................................21 Interpretatie van CoP voor SOA en reconciliatie .....................................................21 Interpretatie van Clark & Wilson model voor SOA en reconciliatie............................25 Risico’s en beheersmaatregelen voor reconciliatie bij SOA ....................................28 Inleiding ............................................................................................................28 Risico’s en beheersmaatregelen voor AO/IC voor reconciliatie bij SOA .....................28 Risico’s applicaties met SOA.................................................................................29 General IT controls voor reconciliatie bij SOA .........................................................31 Inleiding ............................................................................................................31 CoP 10.1.4 Separation of environments ................................................................31 CoP 10.8.2 Exchange agreements ........................................................................32 CoP 10.8.4 Electronic messaging ..........................................................................32 CoP 11.2.2 Privilege management ........................................................................33 CoP 11.5.2 User authentication and identification ..................................................33 CoP 11.4.7 Network routing control en Cop 12.2.3 Message integrity ......................33 Applicatieve beheersmaatregelen op basis van Clark & Wilson ................................34 Reconciliatie voor de financiële verslaglegging.......................................................35 Inleiding ............................................................................................................35 Eisen informatiebeveiliging voor reconciliatie applicatie ..........................................35 Reconciliatie IT controletotalen ............................................................................35 Reconciliatie basisadministratie ............................................................................36 Reconciliatie ontvangstomgeving..........................................................................37 Reconciliatie grootboek .......................................................................................38 Reconciliatie datawarehouse ................................................................................39 Reconciliatie financiële rapportage .......................................................................41 Monitoring en audit trail van de reconciliatie .........................................................41 Positionering van reconciliatieapplicatie ................................................................42 Conclusies en aanbevelingen ...................................................................................43 Inleiding ............................................................................................................43 SOA veroorzaakt risico’s voor de financiële verslaglegging ......................................43 SOA vereist extra aandacht voor general IT controls ..............................................43 Reconciliatie is vereist van de bron tot en met de rapportage bij SOA......................43 Reconciliatie ondersteunt de functiescheiding binnen de financiële verslaglegging ....43 Reconciliatie ondersteunt SOx regelgeving ............................................................43 Reconciliatie informatie als koppeling naar ‘audit around the computer’ ...................44 Tot slot ..............................................................................................................44 Bijlage Literatuurlijst ................................................................................................45
2
1
Inleiding
Deze inleiding heeft als doelstelling de context te creëren voor de IT auditor die gevraagd wordt om het reconciliatieproces te controleren bij een bank met een (deels) service oriented architecture. In dit referaat wordt ingegaan op de keuze door banken voor een Service Oriented Architecture (SOA) en de bijbehorende informatiebeveiligings- en reconciliatieproblematiek voor de administratieve bancaire informatiesystemen bij de banken (ING, ABN Amro, Rabobank e.a.). De ‘Dikke van Dale’ definieert conciliatie als ‘verzoening’ of ‘afstemming tot stand brengen’. Reconciliatie wordt in dit referaat gedefinieerd als het proces dat controleert dat het grootboek aansluit op de gegevens in basisadministraties (sparen, hypotheken, rekening courant, etc.) en andere gegevensverzamelingen, die gebruikt worden voor financiële verslaglegging, zodat de basisadministratie, het grootboek en de rapportages op elkaar zijn afgestemd. Informatiebeveiliging wordt in dit referaat gedefinieerd als het geheel van maatregelen om de vertrouwelijkheid, integriteit en beschikbaarheid van de informatievoorziening te waarborgen. De bancaire sector moet de operationele kosten reduceren om concurrerend te zijn en te blijven. Hierbij is flexibiliteit en dynamiek van bedrijfsprocessen van essentieel belang, zodat stappen in bedrijfsprocessen kunnen worden geoptimaliseerd. In het streven naar de laagste kosten, moeten (delen van) bedrijfsprocessen worden uitgevoerd op de plaats, waar de vereiste kwaliteit geleverd kan worden tegen de laagste kosten. Dit geldt zowel voor de bedrijfsorganisatorische positie (service centra, outsourcing van operationele processen naar lage lonen landen), de informatievoorziening (hosting, outsourcing van IT operatie) als voor de fysieke locatie (o.a. outtasking naar externe call centra). De consequentie is dat vastlegging van financiële gebeurtenissen op diverse locaties plaatsvindt met regelmatig ook verschillende applicaties. Een eenvoudige betalingsopdracht bijvoorbeeld kan vanuit de verschillende plekken worden vastgelegd, zoals met overschrijvingsformulieren, met telefonische opdrachten, via Internet, via mobiele telefoon, via geldautomaten, etc. Door de standaardisatie van de bankproducten doet deze ‘multi-channel’ ontwikkeling zich ook voor bij andere financiële producten (o.a. transactie op financiële markten, effectentransacties, hypotheken, beleggingen en verzekeringen). De bancaire bedrijfsprocessen moeten zich aanpassen aan de nieuwe technologische mogelijkheden. De vereiste flexibilisering van de bedrijfsprocessen in de bancaire sector wordt het laatste decennium geremd door de oude bestaande automatisering. Dit wordt mede veroorzaakt, doordat het vervangen van deze oude applicaties grote investeringen met zich meebrengt. Door de lange doorlooptijd van de migraties is de vraag ontstaan om nieuwe technologische mogelijkheden aan te sluiten op (delen van) de bestaande (legacy) applicaties. De informatietechnologie heeft de object georiënteerde benadering als antwoord op deze vraag. Echter een volledig object-georiënteerde benadering zorgt voor problemen in de aansluiting op de processen. De object georiënteerde programmatuur bevat kennis van de status van bedrijfsprocessen. Hierdoor leidt een wijziging van een bedrijfsproces tot een wijziging van de objectprogrammatuur, waardoor de flexibiliteit van de bedrijfsprocessen wordt beperkt. Deze beperking van de flexibiliteit is één van de voorname redenen, waardoor de objectgeoriënteerde architectuur niet grootschalig is doorgevoerd in de bancaire sector. Een tweede reden is dat de oude systemen niet op deze wijze zijn gebouwd, waardoor integratie van objectgeoriënteerde programmatuur en de oude systemen moeizaam verloopt. De computerindustrie is gekomen met een verbeterde versie van de objectgeoriënteerde benadering, namelijk de Service Oriented Architecture (SOA). De bancaire sector in Nederland heeft inmiddels strategisch gekozen voor de Service Oriented Architecture met integratie en hergebruik van bestaande systemen. In deze scriptie wordt niet verder ingegaan of deze strategische keuze juist is. SOA biedt verschillende mogelijkheden, zowel functioneel als technisch, om de connectie tussen de basisadministraties en het grootboek te realiseren. De keuze voor SOA brengt een aantal consequenties en vraagstukken met zich mee voor de interne controle en financiële verantwoording. In deze scriptie worden deze toegelicht vanuit een IT audit-perspectief.
3
Voor de financiële verantwoording is het noodzakelijk, dat de subadministraties en het grootboek volledig aansluiten. Door de verschillende rapportage-eisen (US GAAP, IFRS, Basel2, etc.) en het vereiste detailniveau voor de diverse rapportages is het niet mogelijk om de volledige rapportage te baseren op alleen het grootboek. De grote leveranciers van grootboeksoftware gebruiken hiervoor aanvullend datawarehouse-technologie, zodat specifieke rapportages kunnen worden geleverd van dezelfde cijfers naar verschillende inzichten. Hierbij is de consistentie tussen het datawarehouses en het grootboek een belangrijk vraagstuk. Daarnaast speelt het vraagstuk welke interne controlemaatregelen getroffen moeten worden om de vertrouwelijkheid, integriteit, beschikbaarheid en controleerbaarheid te waarborgen in de verschillende onderdelen, als gebruik gemaakt wordt van SOA. De financiële verslaglegging bij banken is gebaseerd op de contractadministratie en geldstromen. Hierbij wordt opgemerkt dat de waardenkringloop bij banken (Starreveld) abstracter is dan typologieën met goederen stromen, doordat de contractadministraties worden gezien als producten waarbij de aantallen in geld worden uitgedrukt. Klanten Credit (bijv. Sparen)
Debet (bijv. Lenen)
Verkoop kanalen Registratie Debet/credit
Tegenpartij
Product Te kort/ administraties Overschot/ Risico nemen Afdekken risico Registratie Treasury
Overschot
Funding (debet)
Geconsolideerd grootboek Consolideren
Grootboek per juridische entiteit
Rapportage
Rapportage
Rapportage (IFRS, Basel2 US GAAP)
Figuur 1 Globaal bedrijfsproces van een bank met financiële gegevensstromen
De verschillende bedrijfsprocessen, waarmee financiële producten worden geadministreerd door banken kunnen door verschillende services worden gerealiseerd. In het onderstaande schema wordt weergegeven welk proces een overboeking van een rekening courant naar een spaarrekening doorloopt.
Figuur 2 Overzicht van bedrijfsproces met de processtappen
De verschillende stappen van het bedrijfsproces worden ondersteund met één of meerdere bedrijfsapplicaties, die op verschillende platformen (hardware, operating system, DBMS en netwerken) verwerkt kunnen worden. Deze verschillende bedrijfsapplicaties zullen op de juiste momenten de financiële applicaties moeten voeden met de juiste gegevens.
4
2
Informatiearchitectuur bij banken met SOA
2.1
Service Oriented Architecture bij banken
De informatie architectuur (o.a. James Martin – Strategic data planning) met SOA voor de banken leidt tot een indeling in domeinen. Elk domein is eigenaar van een verzameling gerelateerde gegevens. Zo is het Finance domein verantwoordelijk voor de financiële verantwoording. Voor deze financiële verantwoording ontvangt het financiële domein gegevens zonder hier expliciet om gevraagd te hebben (push services) en haalt het financiële domein gegevens uit andere domeinen (pull services).
Face
Telefoon
E-business
Marketeing
Treasury
Treasury
Risk management
Finance
Credit Service Oriented Enterprise bus (bijv. Sparen)
Money markets
Foreign exchange
Securities
Mortgages
Loans
Savings
Accounts & payments
Customers & parties
De verschillende domeinen communiceren met elkaar via deze services. Om te zorgen dat de verschillende domeinen elkaar verstaan is een zgn. ‘domain exchange model’ noodzakelijk. In dit model wordt op logisch niveau beschreven welke diensten een domein kan bieden (services), welke gegevens aangeboden worden (logische entiteiten en elementen) en de betekenis van deze gegevens (semantiek). De inrichting van domeinen voor de banken in Nederland is een sterke beheersmaatregel, want hierdoor kan de optimalisatie van de systemen per domein plaatsvinden. Voor gefuseerde ondernemingen, zoals ABN AMRO of ING leidt deze optimalisatie tot een beheersbaar proces om per domein de fusies te realiseren en zo het beoogde kostenvoordeel uit de fusies te realiseren. Strategisch biedt deze indeling in domeinen ook de mogelijkheid om delen te outsourcen of af te stoten. 2.2
Applicatie architectuur met SOA
De generieke opzet van SOA is gebaseerd op de logische architectuur bestaande uit applicaties, die samengesteld worden uit services. Voor het realiseren van de applicaties worden verschillende soorten services gebruikt. •
Process centric services – Verzorgen de besturing van een bedrijfsproces, en roepen task centric services aan. In de praktijk wordt de process centric service vaak verward met de task centric service. Echter een essentieel onderscheid tussen beide is dat de process centric service de functiescheiding realiseert en controleert dat een bedrijfsproces binnen de richtlijnen wordt uitgevoerd. Een process centric service zorgt ook dat verschillende processtappen geautomatiseerd kunnen worden uitgevoerd en uitzonderingen correct worden afgehandeld.
•
Task-centric business services – verzorgen de besturing van een bedrijfsprocesstap, waarbij de taak automatisch wordt uitgevoerd (transactie valt binnen de limieten) of een eindgebruiker heeft de autorisatie heeft om de betreffende taak uit te voeren. Door de task centric business services worden de juiste applicatie-services aangeroepen. Hierbij kan de invoer van de gebruiker worden gebruikt om de processtap te realiseren.
5
•
Application services – verzorgen de communicatie tussen de eindgebruiker en het systeem. Dit gebeurt door schermen te tonen, waarop gebruikers hun gegevens zien en kunnen bewerken. Een belangrijke functie van application services is de integriteit tussen entity centric services te bewaken, zodat de response van entity centric services correct wordt afgehandeld.
•
Entity-centric services – verzorgen het beheer van de data objecten, die ter beschikking worden gesteld aan de eindgebruiker. De belangrijke functie van entity centric services is de integriteit van de gegevens te bewaken. Dit wordt gerealiseerd door te zorgen, dat als een functie wordt uitgevoerd, een entiteit altijd in een integere situatie wordt achtergelaten.
Door de verschillende services te combineren wordt het mogelijk om vanuit verschillende kanten een mutatie gerealiseerd te krijgen. 2.3
Logische informatiearchitectuur financiële domein
2.3.1 Overzicht Het financiële domein wordt gevoed met gegevens vanuit de basisadministraties, want daar worden de vastleggingen gedaan, die leiden tot registraties in het grootboek. De vastleggingen worden bij SOA via gebeurtenissen (events) aan het financiële domein gemeld. De events worden door de services in de vorm van berichten (messages) naar het financiële domein verstuurd voor verwerking in het grootboek. Dit kunnen ook massamutaties (batch) zijn, doordat de betreffende gegevens massaal beschikbaar komen. Een voorbeeld hiervan is renteberekening. De events leiden op deze wijze tot registraties in de financiële administratie. Bij een bank worden zowel on-balance als off-balance registraties onderkend. De off-balance mutaties zijn verplichtingen of rechten die een bank aangaat met haar klanten en vormen een materieel onderdeel van de activiteiten van een bank. De on-balance mutaties resulteren in mutaties van balansposten. Daarnaast wordt in de financiële administratie onderscheid gemaakt in registratieve mutaties en resultatieve mutaties. De registratieve mutaties zijn gericht op het veranderen van verplichtingen en rechten met klanten. De resultatieve mutaties zijn gericht op de interne financiële besturing van de bank, bijv. voorzieningen. De event-georiënteerde benadering voor de financiële administratie is gelijktijdig geïntroduceerd met de objectgeoriënteerde wijze van inrichten van de basisadministraties. Voor alle banken geldt echter dat het migreren naar een service oriented architecture en een event-georiënteerd grootboek een zeer grote operatie is, die verschillende jaren in beslag neemt. In de legacy systemen leveren de basisadministraties journaalposten aan i.p.v. events. Bij de legacy systemen wordt de inhoud en het formaat van de journaalposten in de legacy systemen bepaald. Bij eventgeoriënteerde systemen wordt de inhoud en het formaat van de journaalpost bepaald in het grootboek op basis van de kenmerken van de aangeleverde mutatie. De consequentie van het aanleveren van journaalposten door de basisadministraties was, dat de basisadministraties rekening moesten houden met de inrichting van het grootboek. De inrichting van het grootboek kon niet aangepast worden zonder de aanlevering door basisadministraties aan te (laten) passen. Voor het reconciliatieproces had dit als voordeel, dat als de controle tussen basisadministratie en opgeleverde journaalposten correct was en de registratie van de journaalposten in het grootboek correct was, het grootboek als volledig beschouwd werd. Door het aanleveren van journaalposten bevatte het grootboek echter een beperkte hoeveelheid detailinformatie. De ontbrekende detailinformatie is echter wel noodzakelijk om aan de financiële rapportage eisen te voldoen. Een voorbeeld van een eenvoudige wijziging is bijvoorbeeld de indeling van leningen in termijnen. Als DNB besluit deze indeling aan te passen en de indeling in looptijd wordt via journaalposten geregeld vanuit de basisadministratie, dan moet door de nieuwe indeling de aanlevering door de basisadministratie worden aangepast. Om dit te voorkomen worden allerlei bypasses gecreëerd om de detailgegevens toch te combineren met gegevens uit het grootboek, zodat de betreffende rapportages toch opgeleverd kunnen worden. Voor de huidige (regelmatig wijzigende) financiële rapportage bevat een grootboekadministratie onvoldoende detailinformatie om aan de eisen te voldoen. Deze verschillende rapportage eisen ontstaan, doordat banken moeten voldoen aan verschillende richtlijnen en/of (belasting) wetgeving o.a. IFRS, Basel2, DNB rapportages en US GAAP. De juridische organisatievormen (bijvoorbeeld Europese vennootschap = SE) leiden ook tot nieuwe rapportage-eisen. Deze
6
verplichte externe financiële rapportage wordt in dit referaat verder Financial Accounting (FA) genoemd. In de praktijk blijkt het niet mogelijk om met de huidige ERP pakketten (SAP, Peoplesoft, Hyperion, etc.) of maatwerk-software de verschillende rapportage-eisen te realiseren op basis van alleen het grootboek. Als daarnaast ook nog een gedetailleerd inzicht noodzakelijk is t.b.v. management accounting (MA) en financiële sturing (bijvoorbeeld liquiditeitsmanagement, interest management, budgettering) wordt gekozen voor een datawarehouse oplossing. De ERP leveranciers (bijvoorbeeld SAP met Business Warehouse) zijn overgegaan tot de inrichting van een datawarehouse-oplossing binnen hun platform. Een essentiële eis hierbij is dat de basisadministraties, grootboek en datawarehouse consistent zijn, de aansluiting kan worden aangetoond en deze aansluiting door de externe accountant kan worden gevolgd. Hierdoor is het onafhankelijke reconciliatieproces in toenemende mate van belang.
R ec
Reconciliatie verzoeken
n ek e o verz ie iliat onc
Mutatie s
Berichten via gegevens ontvanst omgeving
Reconciliatie verzoeken
n eke verzo iatie ncil Reco
Reconciliatie verzoeken
Reconciliatie verzoeken
Reconciliatie verzoeken
Als gevolg van de vergaande integratie van de automatisering en ‘straight-through-processing STP’ wordt de interne controle gerealiseerd door logische toegangsbeveiliging en applicatieve controlemaatregelen. Het reconciliatieproces verzorgt een onafhankelijke controle op de juiste werking van deze controlemaatregelen door het gebruik van omspannende verbandcontroles. Om de consistentie tussen de verschillende gegevensverzamelingen te waarborgen moet een reconciliatie-model worden gedefinieerd, waarbij het netwerk van controletotalen wordt gerealiseerd. Dit reconciliatiemodel kan op verschillende manieren worden gerealiseerd. Hierbij is het van belang, dat de basisadministraties en het financiële domein rekening houden met de eisen die gesteld worden vanuit de reconciliatie. Deze reconciliatievragen kunnen van verschillende aard zijn. Door deze vragen onafhankelijk van de gegevensverwerking te stellen aan de verschillende administraties kan de consistentie tussen de verschillende administraties worden vastgesteld. In het schema hieronder zijn de vereiste reconciliaties schematisch weergegeven. In de volgende paragrafen worden de componenten nader toegelicht.
en ht ric e b
2.3.2 Basisadministraties De basisadministraties worden gevoerd met pakketten en zelf ontwikkelde applicaties. Deze basisadministraties zijn bronsystemen voor de voeding van het grootboek. De basisadministraties worden regelmatig aangepast voor nieuwe producten en herinrichting van processen. Eerder is al aangegeven, dat de basisadministraties geen kennis van de opzet van het grootboek moeten bevatten, maar de mutaties (events) aan het grootboek moeten aanleveren. Vanuit het grootboek moet duidelijk gedefinieerd worden op welke wijze de gegevens aangeleverd worden. Dit wordt vastgelegd in het domain exchange model. 7
De basisadministraties versturen de ‘events’ naar het grootboek via de ‘message bus’. Hierbij zijn er verschillende type interfaces bij SOA mogelijk: •
Elk event een message, bijvoorbeeld de mutatie van een contract
•
Een batch van messages naar aanleiding van een event, bijvoorbeeld renteberekening
•
Een message over een batchbestand dat met message verstuurd wordt, en vervolgens wordt het batchbestand buiten de bus om opgehaald. Bijvoorbeeld alle betalingstransacties.
•
Alleen een batchbestand met messages geheel buiten de bus om
Tijdens de audit van het reconciliatieproces moet de IT auditor dit onderscheid duidelijk in beeld krijgen, aangezien de verschillende soorten interfaces nadrukkelijk verschillende eisen aan de reconciliatie stellen. Om de operationele activiteiten verder te optimaliseren worden basisadministraties voor verschillende juridische entiteiten bij elkaar gevoegd. De IT auditor zal voor de audit van het reconciliatieproces moeten beoordelen op welke wijze wordt gegarandeerd, dat de mutaties voor de afzonderlijke juridische eenheid, correct worden verantwoord in het grootboek. Ook worden administraties uitbesteed aan externe bedrijven, bijv. ONVZ zorgverzekeringen, die de administratie voor verschillende bedrijven realiseren in één systeem. Ook hier zal de IT auditor moeten verifiëren op welke wijze de verantwoording volledig is. 2.3.3 Ontvangstomgeving In de ontvangstomgeving worden alle gegevens ontvangen, die aangeleverd worden door de basisadministraties. De ontvangstomgeving (staging area) heeft vier belangrijke functies, die impact hebben op het reconciliatieproces: -
De eerste functie is de bewaking dat alle gegevens worden ontvangen. Hiermee wordt operationeel bewaakt, dat de verwachte gegevens ook daadwerkelijk worden ontvangen. Als er bijvoorbeeld dagelijks een batch met rentemutaties moet worden ontvangen en dit gebeurt niet, wordt dit gesignaleerd en kan er actie worden ondernomen. (volledigheid)
-
De tweede functie is het bewaken van de datakwaliteit van de ontvangen gegevens, waarmee wordt gecontroleerd dat de aangeleverde gegevens correct zijn. Deze controle zorgt ervoor dat er bijvoorbeeld geen events worden aangeleverd, die niet verwerkt kunnen worden in het grootboek. (integriteit)
-
De derde functie is het overbruggen van tijdverschillen, want niet alle gegevens komen op hetzelfde moment binnen. De ontvangstomgeving zorgt ervoor dat deze verschillen worden gladgestreken. Mutaties kunnen bijvoorbeeld pas worden verwerkt in het grootboek, nadat een periode in het grootboek is afgesloten. De ontvangstomgeving zorgt dan dat de gegevens worden vastgehouden totdat de periode is afgesloten. (integriteit)
-
De reconciliatie van de ontvangstomgeving met de basisadministratie gebeurt door periodiek een reconciliatie-verzoek af te stemmen. Het initiatief voor deze reconciliatie is een aandachtspunt voor de IT auditor. Enerzijds kan een basisadministratie aangeven, dat een periode is afgesloten (bijv. een uur of een dag), waarbij het initiatief bij de basisadministratie ligt en direct aangeeft welke totalen in de betreffende periode zijn aangeleverd volgens de eisen van het financiële domein. Anderzijds kan het initiatief bij de financiële administratie liggen om een controletotaal op te vragen naar aanleiding van een ontvangen bericht over een afgesloten periode. Deze reconciliatie is essentieel om te bewaken dat alle gegevens zijn geleverd aan de ontvangstomgeving.
2.3.4 Grootboek Het grootboek is de centrale administratie, waarin de registratie van financiële mutaties plaatsvindt. De structuur van het grootboek van een internationale bank is een complex geheel, waarin financiële gegevens volgens verschillende principes worden geregistreerd. De complexiteit van het grootboek zit in de hoeveelheid verschillende inzichten die geboden moeten worden: multi-currency, multi-book, multi-account; multi-legal entity, multi-business, multi-country. De verschillende juridische entiteiten leidt tot de inrichting van verschillende grootboeken binnen de 8
grootboekapplicatie, die vervolgens worden geconsolideerd naar één grootboek voor de holding. Afhankelijk van de karakteristieken van de juridische entiteit kan de inrichting van het grootboek verschillen. Dit leidt ook tot verschillen in eisen voor de reconciliatie. Binnen het grootboek voor een juridische entiteit worden meerdere boeken voor de verschillende producten gecreëerd, waarin de mutaties volgens de verschillende principes worden geregistreerd. De IT auditor moet zich bij de audit van het reconciliatieproces bewust zijn van de grenzen van de onderzochte reconciliatie. Hierbij moet de IT auditor inzicht hebben in de grootboekstructuur van de onderzochte juridische entiteit(en). 2.3.5 Transformatie naar financial logical model – rules engine/ETL De grote diversiteit van mutaties uit de verschillende applicaties moeten worden omgezet naar de grootboeken, waarbij de verschillende principes voor het boeken moeten worden toegepast. Hierdoor heeft het financiële domein behoefte heeft aan een ‘intelligent’ mechanisme, waarmee de gegevens (events) uit de basisadministraties op correcte wijze getransformeerd kunnen worden naar het grootboek-formaat. Deze transformatie bevat de ‘business logic’ van de controller. Deze regels kunnen geprogrammeerd worden in (semi)statische programma’s, maar ook als ‘rules’ met scripts worden gerealiseerd. Om maximale flexibiliteit te creëren voor de controller zijn hiervoor specifiek pakketten op de markt o.a. OST, PEGA-rules, Oracle FSAH, etc. Deze zgn. ‘rules engines’ bevatten een taal, waarmee de transformatieregels dynamisch kunnen worden gedefinieerd. Vanuit een accountants en IT audit-perspectief vereist een ‘rules engines’ module de nodige aandacht, zodat vastgesteld kan worden dat de ‘rules’ consequent (correct) zijn toegepast. Vanuit een reconciliatie-perspectief kan de ‘rules engine’ verschillen veroorzaken. Het reconciliatieproces kan om deze reden als een controlerende functie worden beschouwd op deze transformatie. De ‘rules engines’ bevatten reconciliatie functionaliteit om te reconciliëren tussen input en output. De ‘rules engines’ verwerken in principe elk event afzonderlijk. Dit heeft als consequentie, dat de ‘rules engines’ IT-technisch gezien een zware belasting kan zijn voor de infrastructuur. Ook zijn er semi-statische oplossingen met ETL-programmatuur (= Extract, Transfer, Load). Hiermee worden de rules gedefinieerd om juiste transformaties realiseren. Deze ETLprogrammatuur biedt echter geen standaard reconciliatiemogelijkheden anders dan technische controles dat een verwerking correct is verlopen. De reconciliatie moet dan afzonderlijk worden ontwikkeld. In de logische architectuur is aangegeven, dat de datawarehouse-component tegenwoordig ook een ‘onmisbare’ component is. De datawarehouse-component moet meegenomen worden in de keuze tussen een dynamische en semi-statische oplossing voor de rules engines. Hierbij is de keuze van de rules engine van invloed op de maatregelen om de consistentie tussen grootboek en datawarehouse te bewaken. 2.3.6 Datawarehouse Het financiële datawarehouse kan een subset van het ‘corporate datawarehouse’ of een geïsoleerd datawarehouse zijn. In dit referaat wordt uitgegaan van een financieel datawarehouse dat qua scope overeenkomt met de business scope van FA en MA en verplichte risicorapportages. De kracht van het datawarehouse is gelegen in het feit, dat een datawarehouse veel detailinformatie inclusief historie kan vasthouden. Hierbij kan de detailinformatie in principe naar een oneindig aantal dimensies worden gerapporteerd. De consistentie tussen het grootboek en het datawarehouse is essentieel om een datawarehouse te kunnen gebruiken voor financiële verslaglegging. Hierbij is een belangrijk uitgangspunt dat het grootboek leidend is en het datawarehouse hier op een meer gedetailleerd niveau invulling aan geeft. De IT auditor moet bij de beoordeling van het reconciliatie-proces onderzoeken in hoeverre dit principe niet doorbroken wordt. Dit uitgangspunt biedt een grote mate van flexibiliteit aan het datawarehouse, want hierdoor kan het datawarehouse gekalibreerd worden met de basisadministratie, zodra aangetoond is dat de basisadministratie en het grootboek consistent zijn. Kalibreren is het proces, waarmee het datawarehouse wordt ‘gelijkgetrokken’ met details uit de basisadministratie. Hiermee wordt het relatief eenvoudig om bij een gewijzigd datamodel van de basisadministratie het financieel datawarehouse weer consistent te krijgen. Het is belangrijk te onderkennen dat hiervoor het
9
grootboek wel voldoende detailgegevens moet bevatten om de consistentie tussen de basisadministratie en het grootboek aan te tonen. Het datawarehouse kan gegevens bevatten t.b.v. de FA- en MA-rapportages. Hierbij is het belangrijk, dat bekend is welke gegevens noodzakelijk zijn voor de FA-rapportages en additioneel nodig zijn voor de MA-rapportages. Bij voorkeur wordt er nagestreefd dat de verwerking van deze stromen onafhankelijk plaatsvindt. Hiermee wordt voorkomen, dat door het ontbreken van MAgegevens de FA-verwerking verstoord wordt. 2.3.7 Financial Accounting rapportage De Financial accounting-rapportage (FA) zijn alle verplichte financiële rapportages voor banken aan de diverse externe partijen. Hierbij zijn er diverse wetgevingen, waaraan moet worden voldaan o.a. Wet op de jaarrekening (Titel 9 Boek 2 Burgerlijk Wetboek), US GAAP, IFRS GAAP, Basel2 (financieel risico) en belastingwetgeving. Bij de inrichting van het grootboek wordt hier al rekening mee gehouden door verschillende boeken te hanteren voor de verschillende boekhoudprincipes en/of valuta’s. Hiervoor wordt voor de verschillende indelingen met memoaccounts gewerkt. Uitgangspunt voor de FA rapportages is dat de rapportages opgesteld worden vanuit het grootboek. In de praktijk komen rapportages voor, waarvoor de noodzakelijke details niet beschikbaar zijn in het grootboek. Dit kunnen bijvoorbeeld criteria zijn gerelateerd aan zekerheidsstellingen, landen van zekerheidsstellers, indelingen in rentepercentages en looptijd, typologieën van producten. De regelgeving voor de FA rapportages wordt regelmatig gewijzigd, waarbij er nieuwe eisen worden geïntroduceerd. Als deze wijzigingen consequent in het grootboek zouden moeten worden doorgevoerd, zou de inrichting van het grootboek regelmatig moeten wijzigen. Dit is een ongewenste situatie, want hierdoor wordt de controle van het grootboek over een heel jaar verstoord door aanpassingen en conversies. In het datawarehouse zijn de detailgegevens wel beschikbaar en kunnen de betreffende wijzigingen wel sneller doorgevoerd worden. Als er gegevens uit het datawarehouse worden gebruikt moet via het reconciliatieproces aangetoond worden, dat de geselecteerde gegevens uit het datawarehouse consistent zijn met de grootboekstanden. De IT auditor moet controleren dat deze reconciliatie-stap onderdeel is van de rapportage-procedure. 2.3.8 Management Accounting rapportage De Management Accounting-rapportage (MA) is noodzakelijk voor de besturing van de organisatie. Vanuit de organisatie is er een sterke informatiebehoefte om de grootboekgegevens te gebruiken voor het plannen en begroten van de toekomst. Daarnaast is er voor de besturing vaak ook andere detailinformatie noodzakelijk, bijvoorbeeld HR gegevens, bezettingsresultaten, etc. Binnen het bankbedrijf wordt voor deze informatie ook gebruik gemaakt van datawarehouse technologie. 2.4
Technische SOA infrastructuur
Deze paragraaf beschrijft de SOA infrastructuur. Het schema op de volgende pagina geeft een generieke vereenvoudigde infrastructuur. Hieruit blijkt dat er op verschillende punten overdracht van gegevens plaatsvindt. De overdrachtspunten vormen risico’s voor de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens. De message infrastructuur moet hierdoor voldoen aan stringente security eisen.
10
Voor het realiseren van de technische SOA infrastructuur moeten een aantal componenten worden onderscheiden: 1. Message broker (server met middleware bijv. WEB Sphere/MQ Series of Oracle Fusion) De message broker verzorgt de gegevensuitwisseling tussen de verschillende applicaties. Daarnaast verzorgt de ‘message broker’ op functioneel niveau dat de gegevensberichten volledig en correct worden aangeleverd. De message broker verzorgt hiermee de BUSfunctionaliteit. De message broker bestaat uit een server-applicatie en een client-applicatie. De server-applicatie zorgt voor de distributie en het beheer van de berichten. De clientapplicatie communiceert met de business-applicatie. De ontvangstomgeving in het financiële domein maakt intensief gebruik van de client-functionaliteit. Er worden verschillende type messages onderkend, waarvan de volgende de meest bekende zijn: ●
Push message – een message wordt door een domein naar een ander specifiek domein verzonden als gevolg van het optreden van een gebeurtenis. Optioneel kan de verzender om een expliciete ontvangstbevestiging vragen. Deze vorm wordt vaak gehanteerd voor informatie die verzonden wordt naar het financiële domein. Essentieel is dat het verzendende domein zich bewust is naar welk domein de message wordt verzonden. Het voordeel is dat het verzendende domein invloed heeft op het moment dat de actie wordt uitgevoerd. Dit kan in het geval van performance-kritische systemen een overweging zijn om deze message typologie te hanteren.
●
Pull message – een message wordt naar een ander domein verzonden met een verzoek om gegevens, die als response worden teruggegeven. Hiermee kan het financiële domein o.a. reconciliatie-gegevens ophalen uit een ander domein, maar ook een ‘batch van mutaties’. Hierbij is essentieel dat het vragende domein zich bewust is uit welk domein de gegevens moeten komen. Als het financiële domein de vragende partij is, kan dit als voordeel hebben dat de vraag gesteld wordt op het moment dat de gegevens nodig zijn. Hierdoor beschikt het financiële domein over de meest recente situatie. De belasting van de beantwoordende systemen kan hierbij een rol spelen.
●
Fire forget – een message wordt vanuit een domein verzonden en alleen op de bus geplaatst, zodat andere domeinen deze message van de bus kunnen halen als zij dit willen. Hierbij is essentieel dat de verzender zich niet bewust is wie het bericht van de bus haalt en de message ook niet nogmaals zal versturen. Dit type mag alleen worden gebruikt voor niet-kritische gegevens. Het financiële domein maakt zelden gebruik van dit type message. Het grote voordeel dit type berichten is dat er minimale eisen aan de exchange agreement gesteld worden. Dit vereist wel dat de ontvanger continu controleert (listner) of er berichten op de bus worden geplaatst, die bestemd zijn voor het
11
betreffende domein. Het risico van deze berichtensoort is dat als de ‘listner’ tijdelijk niet beschikbaar is, de berichten voorgoed verloren zijn. Dit is een onwenselijke situatie voor het financiële domein. Deze drie soorten zijn slechts een selectie uit de vele typen messages. Voor de reconciliatie moet de IT auditor aandacht schenken aan de keuzes die zijn/worden gemaakt voor het berichtenverkeer, zodat de volledigheid van het berichtenverkeer is gewaarborgd. Een belangrijk aandachtspunt voor de IT auditor is wie direct toegang heeft tot de messagebrokers, want hiermee kunnen direct messages worden gecreëerd en verzonden. Hiermee kan de integriteit van de gegevens worden verstoord. Dit kan leiden tot fouten in de financiële verslaglegging. Het reconciliatieproces kan deze ‘verstoringen’ aan het licht brengen. 2. Netwerk De SOA infrastructuur kan alleen werken als er een netwerk is. Een belangrijke reden voor het ontstaan van de Service Oriented Architecture is het feit dat applicaties over verschillende (sub)netwerken moeten werken en er online data verkeer noodzakelijk is tussen de verschillende applicaties. De message broker zorgt dat de communicatie tussen de netwerken en de applicaties gerealiseerd wordt. Hiermee worden versieverschillen tussen de verschillende netwerken en business applicaties opgelost zonder dat hier op applicatieniveau maatregelen moeten worden getroffen. Voorbeelden van dergelijke overbruggingen zijn proprietary software in telefooncentrales, die berichten moeten versturen naar operationele systemen. Bij de reconciliatie is het van belang om duidelijk te krijgen dat de verstuurde en ontvangen berichten tussen de verschillende netwerken consistent zijn. De technische reconciliatie kan eventuele verschillen aan het licht brengen. 3. Firewall voor externe connecties De message broker applicatie moet op de juiste wijze geautoriseerd worden in de firewall om te kunnen communiceren met andere netwerken. De message broker kan hierbij ook encryptie en decryptie faciliteiten bieden. In de DMZ kan een message client staan om berichtenverkeer tussen de WEB-server en de message-broker te verzorgen. De firewall moet zo specifiek mogelijk worden ingericht, zodat de messages niet misbruikt kunnen worden voor andere doelstellingen dan is bedoeld met de messages. In de opzet van de messages moet specifiek worden bepaald welke messages wel en niet ‘extern’ gebruikt mogen worden. De ‘externe’ messages en firewall instellingen zijn onderhevig aan de procedure voor review van externe connecties. De IT auditor moet controleren dat de instellingen en messages ook daadwerkelijk door de review commissie zijn beoordeeld. 4. Applicatie servers (zowel WEB-server voor Internet als interne applicatie servers) De applicaties communiceren met de message broker. Hiervoor wordt op de applicatie server een message client geïnstalleerd. De business applicatie stuurt naar en ontvangt berichten van deze client. De client stuurt vervolgens deze berichten naar de message-broker, die de berichten verstuurt naar de volgende applicatie of plaatst deze op de ‘bus’. De message client werkt ook als een zgn. ‘listner’. Dit proces controleert constant welke berichten op de bus geplaatst worden. Op het moment dat de ‘listner’ een bericht leest, dat gewenst is door de betreffende client, wordt dit gelezen en verwerkt door de applicatie. 5. Werkstations van gebruikers De werkstations van de gebruikers (intern en extern) communiceren met de server applicatie. Bij de opzet van SOA roepen de gebruikers services aan. Deze services worden direct aangeroepen bijvoorbeeld vanuit een WEB-applicatie.
12
3 Reconciliatieproces voor financiële verslaglegging 3.1
Inleiding
In het vorige hoofdstuk is beschreven, dat een reconciliatieproces voor de gegevensverwerking noodzakelijk is voor het financiële rapportageproces. In dit hoofdstuk wordt het reconciliatieproces beschreven vanuit de AO/IC voor de controller van een bankbedrijf. Uitgangspunt voor het reconciliatieproces is de functiescheiding beschreven door Starreveld: •
Beschikken – In veel gevallen is dit proces binnen het bankbedrijf volledig geautomatiseerd d.m.v. logische toegangsbeveiliging en limietensysteem, waarbinnen een externe klant kan beschikken over de faciliteiten (geld op rekening-courant, kredietlimiet, etc.) en hier zonder tussenkomst van een bankmedewerker over kan beschikken. In een aantal gevallen is het vaststellen van de limieten ook geautomatiseerd.
•
Uitvoeren – Er is in het algemeen een beperkte goederenstroom binnen een bank. De uitvoeringsfunctie (operations) is bij banken met name gericht op het correct vastleggen van financiële mutaties voor klanten. Ook het vastleggen van deze mutaties is vaak in hoge mate geautomatiseerd.
•
Bewaren – De bewaarfunctie bij banken bestaat uit twee categorieën te weten een echte bewaarfunctie (bijv. kluisruimte, chartaal geld en effectenstukken) en een meer abstracte bewaarfunctie, namelijk het beheren van girale saldi in geautomatiseerde systemen.
•
Registreren – De registratiefunctie is in het algemeen centraal belegd bij de controller van een bank. Met deze registrerende taak moet de controller aantonen (o.a. vanuit SOxwetgeving en wetgeving voor jaarrekening, IFRS GAAP), dat het grootboek een getrouwe weergave van de werkelijkheid is. Door de controle van het grootboek door de interne en externe accountant toont de controller aan, dat de registrerende functie is vervuld. Als een bankbedrijf volgens verschillende ‘accounting principles’ de registratie voert, dan levert het reconciliatieproces een bijdrage aan het verklaren van verschillen in de rapportages tussen de diverse ‘accounting principles’ (bijv. US GAAP versus IFRS GAAP).
•
Controleren – In de basisadministraties en financiële administratie zijn diverse interne controlemaatregelen getroffen, o.a. functiescheiding, general IT controls, application controls, om de volledigheid van de financiële verslaglegging te waarborgen. Het reconciliatieproces controleert de omspannende controletotalen, zodat de werking van de interne controlemaatregelen kan worden gevalideerd.
Het bankbedrijf is in hoge mate geautomatiseerd, waardoor de beschikkende, uitvoerende, bewarende en registrerende functie grotendeels geautomatiseerd plaatsvindt. De geautomatiseerde reconciliatie zorgt ervoor, dat ook deze controle automatisch gaat. In deze scriptie worden in het financiële domein de volgende rollen onderscheiden: 1. Operational controller – de financiële controller verantwoordelijk de registratieve mutaties in het grootboek voor verschillende juridische entiteiten; 2. Business unit controller – verantwoordelijk de resultatieve mutaties in het grootboek per juridische entiteit (bijv. Postbank, ING Bank) en verantwoordelijk voor de financiële rapportage voor de betreffende juridische entiteit; 3. Holding controller – verantwoordelijk voor de consolidatie van verschillende juridische entiteiten en de financiële rapportage van de holding; 4. Toezichthoudende reconciliatie functionaris – verantwoordelijk voor de controle op de operational controller en business controller t.a.v. administratieve reconciliatieprocedures die gevold moeten worden door de operational- en business controller. De toezichthoudende rol op de business unit moet organisatorisch worden opgehangen bij de holding controller. Indien er business unit controllers zijn die verantwoordelijk zijn voor meerdere juridische entiteiten, dan kan de rol voor afzonderlijke juridische entiteiten worden opgehangen als staffunctionaris bij de business unit controller. Essentieel is dat de toezichthoudende rol onafhankelijk is van de operational controller en business controller.
13
3.2
Doelstelling reconciliatieproces
De doelstelling van het reconciliatieproces is: 1. Controleren dat alle transacties zijn vastgelegd en volledig zijn geregistreerd in het grootboek (volledigheid registratieve mutaties); 2. Controleren dat alle resultatieve financiële mutaties zijn vastgelegd en volledig zijn geregistreerd in het grootboek (volledigheid resultatieve mutaties); 3. Controleren dat de opgeleverde financiële rapportages alle transacties verantwoorden, die volgens de specificaties van de rapportages moeten worden gerapporteerd en overeenkomen met de waarden uit het grootboek (volledigheid rapportages). 4. Verklaren verschillen tussen verschillende ‘accounting principles’, die gehanteerd worden voor de financiële verslaglegging. 3.3
Processtappen
Bij banken wordt de functiescheiding gerealiseerd met logische toegangsbeveiliging. De general IT controls zorgen ervoor dat de juiste procedures worden gevolgd door de IT organisatie, zodat aangetoond kan worden dat de logische toegangsbeveiliging correct werkt. Daarnaast worden er geprogrammeerde applicatie controles gerealiseerd (bijvoorbeeld limieten), die controleren of de betreffende gebruiker binnen de (directie)richtlijnen blijft. Deze interne controlemaatregelen zijn preventief. Praktisch alle registrerende processen verlopen bij de banken ook volledig geautomatiseerd. De controller moet in staat worden gesteld om te controleren, dat de geautomatiseerde verwerking van de basisadministraties tot en met de uiteindelijke financiële verslaglegging correct is verlopen. Hiervoor moet de controller een controleproces inrichten. Dit reconciliatieproces bestaat uit verschillende stappen, waardoor met toenemende zekerheid kan worden aangetoond, dat de eerder gedefinieerde doelstellingen worden gerealiseerd.
Stap 1 Controleer de volledigheid van de ICT verwerking Voordat de reconciliatie van de financiële gegevens kan plaatsvinden moet eerst vastgesteld worden, dat de ICT-verwerking correct heeft plaatsgevonden. Hiervoor worden in de verwerking controletotalen op bestanden en databases bepaald en vergeleken. Hiermee wordt aangetoond, dat technisch alle mutaties aan het financiële domein zijn aangeleverd en verwerkt. Met SOA is het belangrijk om synchronisatiepunten te hebben, zodat vastgesteld kan worden dat alle messages technisch correct zijn verwerkt. De eerste stap is dus om de bevestiging te krijgen van de ICT afdeling, dat de technische gegevensverwerking is afgerond en correct is verlopen.
Stap 2 Controleer de volledigheid van stamgegevens in het grootboek In de moderne grootboektoepassingen (Peoplesoft Enterprise General Ledger, SAP ERP GL, Hyperion Essbase) wordt veel detailinformatie vastgelegd, zodat deze gebruikt kan worden voor de verschillende rapportage-eisen. Hiervoor is een grote hoeveelheid stamgegevens noodzakelijk. Dit zijn o.a. organisatiestructuur(mutaties), klant(mutaties), product(mutaties), tarieven(mutaties). Deze gegevens worden deels vastgelegd in het grootboek. Het kenmerkende van deze gegevens is dat zij geen financiële waarde vertegenwoordigen. Voor de controle van de volledigheid van deze gegevens krijgt de controller van de basisadministraties controletotalen vanuit verschillende dimensies, bijv. aantallen klanten gedifferentieerd naar segmenten. Er moeten duidelijke afspraken zijn op welk moment de totalen worden bepaald. De operationele systemen moeten deze informatie onafhankelijk bepalen van de aanlevering van de gegevens aan het financiële domein. Bij de vaststelling van de controletotalen moet nadrukkelijk bewaakt worden, dat het grootboek een vergelijkbaar controletotaal kan opleveren. Het kenmerkende voor deze controletotalen is dat dit GEEN financiële controletotalen zijn. De volledigheid van de niet-financiële mutaties moet vastgesteld worden, want anders kunnen er mogelijk ook financiële mutaties niet verwerkt worden door het ontbreken van de stamgegevens. De afgekeurde financiële mutaties kunnen daardoor op tussenrekeningen terechtkomen. 14
Stap 3 Controleer de volledigheid van contracten en posities in het grootboek De controle van contracten en posities is een controle, waarbij de aantallen en financiële posities in de basisadministraties vergeleken worden met de controletotalen uit het grootboek op een specifiek moment. Deze momentopname is het typerende kenmerk voor deze controle. Ook bij deze controle moet bij de opzet nadrukkelijk beoordeeld worden of het grootboek de controletotalen op identieke wijze kan vaststellen. Deze controletotalen worden per productgroep(segment) vastgesteld. Ook hierbij is het moment van het vaststellen van het controletotaal essentieel, waarbij als uitgangspunt geldt dat de administratieve verwerkingsdatum (dus niet valutadatum) als richtlijn geldt. Indien de boekdatum niet per definitie dezelfde datum is als de administratieve datum moet de IT auditor vaststellen op welke wijze vastgesteld wordt dat het controletotaal een duidelijk gedefinieerd moment is en deze ook vast te stellen is in het grootboek. Dit kan betekenen dat deze gegevens additioneel doorgegeven moeten worden aan het grootboek.
Stap 4 Controleer de volledigheid van mutaties in het grootboek Deze stap controleert dat alle mutaties, die tot een registratieve mutatie moeten leiden, ook daadwerkelijk zijn doorgegeven aan het grootboek. De controletotalen bestaan uit aantallen, totaal toename saldi en totaal afname saldi. Het kenmerkende van deze controletotalen is dat deze over een periode gelden. De periode van de mutaties moet gelijk zijn aan de periode tussen twee reconciliatiemomenten van de contracten en posities. Hiermee kan het omspannende controletotaal worden bepaald: Beginsaldo periode + toename – afname = eindsaldo periode
Stap 5 Controleer de volledigheid van resultatieve mutaties in het grootboek De resultatieve mutaties zijn mutaties die in het grootboek worden aangebracht als gevolg van de analyse van de registratieve mutaties. Het toenemen van het kredietrisico kan leiden tot additionele reserveringen. Ook kan op basis van de resultaten bepaald moeten worden welke overige voorzieningen getroffen moeten worden, zoals ‘te betalen belasting’. Voor deze resultatieve mutaties gelden verschillende regels en elke periode moeten deze mutaties worden uitgevoerd. De volledigheid van deze resultatieve mutaties wordt in het algemeen procedureel afgehandeld. Na afronding van de resultatieve mutaties kunnen de controletotalen voor deze mutaties worden bepaald.
Stap 6 Controleer de consistentie tussen grootboek en datawarehouse De controletotalen van het grootboek zijn na de vergelijking met de basisadministratie leidend. Het datawarehouse moet zich conformeren aan het grootboek. De opbouw van het datawarehouse is echter een aparte applicatie (ETL en/of rules engine). Hierdoor zouden verschillen kunnen ontstaan. De controletotalen, bepaald bij stap 1 t/m 4, moeten dan ook gereconcilieerd worden met de controletotalen in het datawarehouse. Het datawarehouse moet hiervoor dezelfde selectiecriteria hanteren als het grootboek. Hierbij is het belangrijk dat er ook controletotalen zijn die ALLE gegevens selecteren, want het risico van controletotalen is dat er producten niet geselecteerd worden voor het controletotaal, maar later wel in de rapportages worden opgenomen.
Stap 7 Controleer de rapportage gebaseerd op het grootboek en datawarehouse De rapportage wordt gemaakt op basis van het grootboek (eerste keuze) en het datawarehouse (indien het grootboek onvoldoende details bevat). Bij de gemaakte FA rapportages moet gecontroleerd worden dat de totalen van de rapportage aansluiten met het grootboektotalen en de datawarehouse-totalen. Deze controle moet onderdeel zijn van de definitieve goedkeuring van de FA rapportage. Tenslotte moet de gehele rapportagebasis en rapportage worden bevroren, zodat hierop geen wijzigingen meer kunnen plaatsvinden.
15
3.4
Reconciliatierapportages
De reconciliatie rapportages zijn de audit trail van het reconciliatieproces. Ook de reconciliatie kan in grote mate geautomatiseerd worden. Bij materiële afwijkingen moet de controller onderzoek gaan uitvoeren. Nadrukkelijk moeten hierbij richtlijnen gegeven worden, die bepalen of een afwijking wel of niet materieel is. Dit kan in percentages, absolute bedragen of een combinatie van beide. In de administratieve procedure voor de controller moet worden opgenomen, dat het reconciliatieverslag wordt afgetekend in combinatie met de bijbehorende grootboekverslagen. 3.5
Functiescheiding binnen het reconciliatieproces
De hoge mate van automatisering binnen het bankbedrijf leidt ertoe, dat de functiescheiding wordt gerealiseerd met logische toegangsbeveiliging en applicatieve maatregelen. Ook in het reconciliatieproces kan er functiescheiding worden aangebracht. De controle op de reconciliatie moet door een functionaris worden uitgevoerd die niet verantwoordelijk is voor de verwerking van de gegevens. Deze controlerende functionaris moet in een onafhankelijke eenheid vallen. In mijn opzet is dit het team financiële administratieve organisatie, maar dit zou ook een interne audit afdeling kunnen zijn. Desgewenst kan ook functiescheiding worden aangebracht tussen de verschillende controle stappen.
16
4
Wettelijk en theoretisch kader
4.1
Inleiding
In dit hoofdstuk wordt de Service Oriented Architecture en de financiële reconciliatie gepositioneerd voor een aantal relevante theoretische en wettelijke kaders. Uit de beschikbare kaders zijn de volgende gekozen: •
Financiële Instellingen Risicoanalyse Methode van de Nederlandse Bank (FIRM)
•
ISO 17799 Code of practice for information security management (CoP)
•
Sarbanes Oxley act 404 (SOx)
•
Clark & Wilson model (C&W)
De context van Financial Instellingen Risicoanalyse Methode (FIRM) heb ik gekozen, doordat hiermee nadrukkelijk gekeken wordt naar de risicobeoordeling door banken. Hiermee worden de risico’s geïnventariseerd, die de implementatie van SOA met zich meebrengt gezien vanuit DNB. Daarnaast wordt beschreven welke risico’s juist worden gemitigeerd door de opzet van reconciliatie, zodat het netto risico aanvaardbaar is en door financiële reserves kan worden afgedekt. De US Act 404 Sarbanes Oxley (SOx) geeft richtlijnen (control objectives), die gericht zijn op de beheersing van de informatiesystemen betrokken bij financiële verslaglegging van ondernemingen, die genoteerd zijn aan de Amerikaanse beurs (bijv. ABN AMRO en ING). In deze paragraaf wordt ingegaan op welke wijze SOA consequenties heeft voor de IT controls van Sarbanes Oxley. In dit referaat wordt beschreven op welke wijze SOA en het reconciliatiemodel een bijdrage leveren aan de versterking van de interne controle, die vanuit SOx wordt geëist. De ISO 17799 Code of Practice for information security (CoP) management geeft invulling aan de general IT controls . De CoP richt zich nadrukkelijk op de maatregelen van de vertrouwelijkheid, integriteit en beschikbaarheid. In dit referaat wordt beschreven welke van de controls relevant zijn voor de implementatie van SOA en reconciliatie. Het Clark & Wilson model wordt in dit referaat gebruikt om de applicatieve richtlijnen voor de integriteit van de gegevens te waarborgen voor de implementatie van SOA en reconciliatie. Er zijn verschillende richtlijnen en wetten (o.a. US GAAP, Basel2 en IFRS) voor de financiële rapportage door financiële instellingen, maar deze richten zich nadrukkelijk op de eisen aan de financiële rapportage en de correcte interpretatie van de financiële gegevens. Deze richtlijnen zijn wel essentieel voor de financiële verslaglegging, maar zijn minder gericht op interne controle en daardoor minder relevant voor de beheersing van de IT. Om deze reden wordt in dit referaat niet verder op deze richtlijnen ingegaan. 4.2
Interpretatie FIRM voor SOA en reconciliatie
4.2.1 Inleiding De banken staan onder het toezicht van De Nederlandsche Bank. Voor de risico bepaling bij financiële instellingen gebruikt DNB FIRM, Financiële Instellingen Risicoanalyse Methode. DNB brengt hiermee het risicoprofiel van de verschillende financiële instellingen objectief in beeld. De techniek bestaat uit verschillende onderdelen: a) Solvabiliteitspositie en solvabiliteitsbeheersing; b) Liquiditeitspositie en liquiditeitsbeheersing c) Organisatie en beheersing d) Integere bedrijfsvoering Vanuit IT audit perspectief is met name groep C, Organisatie en beheersing, relevant, want hierin worden de IT-risico’s geanalyseerd en beoordeeld. Binnen FIRM worden twee bronnen van risico’s onderkend, namelijk risicocategorieën en beheersingscategorieën.
17
Risicocategorieën Financiële risico's Niet-financiële risico's Matching-/renterisico Omgevingsrisico Marktrisico Operationeel risico Kredietrisico Uitbestedingsrisico Verzekeringstechnisch risico IT-risico Integriteitsrisico Juridisch risico
Beheersingscategorieën Risicospecifieke beheersing Organisatie Management Solvabiliteitsbeheersing Liquiditeitsbeheersing
Het IT-risico wordt gedefinieerd als het risico dat bedrijfsprocessen en informatievoorziening onvoldoende integer, niet continu of onvoldoende beveiligd worden ondersteund door IT. Binnen de categorie IT-risico worden de volgende risico items onderkend: a) Strategie en beleid – het risico als gevolg van het niet of onvoldoende toegesneden zijn van IT- strategie en IT- beleid op de bedrijfsprocessen en de bestaande informatie- en dataverwerking, waardoor onvoldoende ondersteuning wordt geboden aan processen en informatievoorziening. b) Beveiliging – het risico als gevolg van •
Het onvolledig of inaccuraat zijn van de informatie, de informatiesystemen en/of de processen;
•
Het niet toegankelijk zijn van de informatie voor geautoriseerde gebruikers;
•
Het toegankelijk zijn van informatie voor ongeautoriseerde gebruikers.
c) Beheersbaarheid – het risico als gevolg van •
Ontoereikende beheersing van de ICT-omgeving en/of processen;
•
Het onvoldoende (tijdig) kunnen anticiperen op ontwikkelingen in de business, op technische innovatie of op overige externe factoren.
d) Continuïteit – het risico dat de continuïteit van de (kritische) bedrijfsprocessen en/of de gehele instelling in gevaar komt als gevolg van het onbeschikbaar zijn van de ITinfrastructuur (waaronder applicaties en systemen). De IT-risico’s moeten adequaat worden afgedekt door IT-beheersmaatregelen. FIRM zegt niets over de specifieke maatregelen die moeten worden getroffen. In de volgende paragraaf wordt het kader voor deze maatregelen beschreven a.d.h.v. de Code of Practice for information security management. Voor de beoordeling van het inherente IT-risico hanteert DNB een viertal gradaties, namelijk: 1. Laag inherent risico – geringe kans dat het optreden van het risico leidt tot hoge impact; 2. Beperkt inherent risico – wijziging van omstandigheden zou kunnen leiden tot hoge impact. Dit risico moet bewaakt worden. Hiervoor moeten maatregelen getroffen zijn; 3. Aanzienlijk inherent risico – aanmerkelijk hoge waarschijnlijkheid dat het optreden van het risico leidt tot hoge impact; 4. Hoog inherent risico – het risico zal zich, zonder adequate beheersing, zeker voordoen en een aanzienlijke tot hoge impact hebben. De beheersing van het risico door de instelling verdient grote aandacht. Uitgangspunt voor FIRM is dat een instelling door het treffen van beheersmaatregelen het inherente risico kan reduceren. Er zal altijd een restrisico overblijven, waarvoor de financiële instellingen dan financiële reserves moet aanhouden.
18
Voor de banken is het hierdoor financieel aantrekkelijk om goede beheersmaatregelen te treffen.
De beoordelingscriteria voor de beheersing van de IT-risico’s richt zich op de volgende categorieën: 1. Risico-identificatie – worden IT-risico’s adequaat onderkend en zijn hier standaard processen voor ingericht. Dit kan plaatsvinden door business impactanalyses uit te laten voeren voor de verschillende ICT-componenten. Daarnaast kan door een CIA-rating mechanisme worden aangetoond, dat een beoordeling is gemaakt van de IT-risico’s. 2. Risicobeleid – duidelijke richtlijnen en beleid voor IT-organisatie op welke wijze de risico’s moeten worden beheerst. 3. Risicobewaking – IT-management zorgt ervoor dat zij inzicht hebben in de risico’s, dat de risico’s worden bewaakt en dat zij op de hoogte zijn van de regelgeving t.a.v. IT. 4. Organisatie – binnen de IT-organisatie worden de risico’s beheerst d.m.v. IT-governance, security management proces, management richtlijnen en adequate beschrijving en inrichting van de taken, verantwoordelijkheden en bevoegdheden van de IT organisatie. 5. Beveiligingscriteria – vertrouwelijkheid, integriteit en continuïteit is gewaarborgd 6. Beheerprocessen – de verschillende IT-processen zijn adequaat ingericht (bijv. volgens ITIL of Cobit4). 7. Systeem c.q. applicatiegebonden – systemen en applicaties maken maximaal gebruik van de mogelijkheden van geprogrammeerde controles en beveiligingsfaciliteiten. De risicobeheersmaatregelen die getroffen zijn, reduceren het risico. DNB verwacht van de financiële instellingen in Nederland, dat zij zichtbaar maken welk netto risico resteert na het nemen van de beheersmaatregelen. Voor het resterende netto risico moeten de financiële instellingen een reserve aanhouden bij DNB. Deze reserve gaat voor de volle 100% af van het economisch kapitaal van de financiële instelling. Daarom is dit onvoordelig voor de financiële instellingen. De controllers van de financiële instellingen streven ernaar deze verplichte reserve zo laag mogelijk te houden. Hiermee heeft DNB een krachtig instrument om beheersmaatregelen bij de financiële instellingen af te dwingen. 4.2.2 FIRM analyse en SOA Het inherente IT-risico bij de banken (ING, Fortis, Rabobank, ABN Amro e.d.) in Nederland wordt als hoog beoordeeld door de DNB om o.a. de volgende redenen: 1. Internationale geografische spreiding 2. IT omgeving ondersteunt Asset & Liability management, trading en brokerage 3. Transacties door klanten rechtstreeks op het Internet 4. Veel verschillende platformen, applicaties en leveranciers 5. Veel IT projecten per jaar 6. IT systemen zijn beperkt geïntegreerd
19
7. Er vinden aanzienlijke wijzigingen in de functionaliteit van applicaties plaats 8. Aanzienlijke externe koppelingen met systemen bij andere partijen 9. Aanzienlijke hoeveelheid administratieve mutaties en transacties Dit hoge risico vereist sterke (risicomitigerende) beheersmaatregelen, zodat het netto risico gereduceerd wordt tot een aanvaardbaar niveau volgens de richtlijnen van DNB. Voor dit netto risico moeten dan financiële reserves worden aangehouden. De implementatie van SOA brengt een aantal inherente IT-risico’s met zich mee, waarvoor IT beheersmaatregelen moeten worden getroffen. De toename van IT-risico’s moet worden afgewogen tegenover de versterking van de beheersmaatregelen in de andere DNB risicocategorieën die door de implementatie van SOA en het reconciliatie model wordt gerealiseerd. De beheersing op de volgende gebieden wordt versterkt: •
Matching- en renterisico o
•
•
De voor de risicomodellering gehanteerde data wordt actueler. Door de reconciliatie wordt de volledigheid, juistheid en betrouwbaarheid verhoogd. Door de reconciliatie kan het financieel datawarehouse worden gebruikt om de risicomodellering verder te versterken en de analyse horizon te versterken, doordat de gegevens uit het grootboek gecombineerd worden met externe bronnen.
Marktrisico o
Identiek aan het matching- en renterisico.
o
Met SOA wordt het mogelijk om uitgevoerde transacties, ingenomen risicoposities en aangegane verplichtingen juister, tijdiger en vollediger vast te leggen. SOA biedt de mogelijkheid om vanuit de verschillende domeinen ‘near real-time’ de gegevens te verwerken, zodat de limieten adequaat bewaakt kunnen worden. De reconciliatie kan vervolgens bewaken, dat aangegane risico’s voldoende zijn afgedekt.
Kredietrisico o
Met SOA kunnen de relevante kredietrisico’s zeer frequent en gedetailleerd in kaart worden gebracht. Op basis van het grootboek zijn de kredietrisico’s bekend. Het financieel datawarehouse biedt de mogelijkheid om de details toe te voegen en bij gewijzigde risicomodellen toch de juiste aspecten in kaart te brengen. De reconciliatie tussen grootboek en financieel datawarehouse zorgt dat DNB het datawarehouse als bron accepteert.
o
De informatie-eisen voor het kredietrisico is om frequente, juiste en volledige informatie over de kredietposities te bieden. SOA biedt de mogelijkheid om de risicoposities veel sneller integraal in beeld te hebben. Het datawarehouse biedt de mogelijkheid om een verdieping aan het brengen in de aard van de kredietposities, en flexibel andere indelingscriteria te kiezen voor de rapportage en de bijbehorende voorzieningen. De reconciliatie bewaakt de volledigheid.
De IT auditor moet bij het beoordelen van het reconciliatieproces inzicht hebben op deze financiële risico’s en consequenties voor het economisch kapitaal bij de financiële instellingen. Bij de audit van het reconciliatieproces moet specifiek aandacht worden geschonken aan de volledige verantwoording van deze risico’s. Vanuit de DNB wordt vereist dat banken deze volledigheid over het gehele risico management proces inzichtelijk kunnen maken. Voor het reconciliatieproces met SOA moet worden vastgesteld op welke wijze de ‘pipeline’ transacties correct in de risicoposities worden opgenomen, zodat een consistent beeld tussen de risicoposities ontstaat. Het reconciliatieproces kan dit verzorgen door bij de controletotalen de ‘pipeline’ transacties te verbijzonderen.
20
4.3
Interpretatie SOx voor SOA en reconciliatie
4.3.1 Richtlijnen SOx De richtlijnen van US Act Section 404 Sarbanes Oxley (SOx) vereisen dat het management jaarlijks rapporteert over de beoordeling van het bestaan en de werking van de interne controlemaatregelen voor de financiële verslaglegging. Deze beoordeling moet minimaal de volgende componenten bevatten: 1. Een verklaring dat het management verantwoordelijk is voor de opzet en werking van de interne controle van de financiële rapportage. 2. Een verklaring van het uitgangspunt voor het normenkader voor de interne controle (bijv. COSO in combinatie met Cobit4), dat gebruikt is door het management om te beoordelen of de interne controlemaatregelen effectief zijn. 3. Een beoordeling van de opzet en werking van de interne controlemaatregelen voor de financiële rapportage. 4. Bekendmaken van de materiële tekortkomingen, die zijn geconstateerd tijdens de beoordeling van de interne controlemaatregelen m.b.t. de financiële rapportage. 5. Het controlerapport van de onafhankelijke auditor op de door het management uitgevoerde beoordeling van het stelsel van interne controlemaatregelen. Vanuit SOx wetgeving ontstaat hierdoor de noodzaak voor een duidelijk kader voor de interne controle. Dit kader bestaat enerzijds uit interne controlemaatregelen voor de bedrijfsprocessen gericht op financiële verslaggeving, anderzijds uit interne controlemaatregelen voor de ITorganisatie. Voor het bepalen van de IT-beheersmaatregelen kan het IT-management putten uit vele verschillende richtlijnen, waaruit het IT management een samenhangend stelsel moet maken dat is toegesneden op de organisatie en de IT processen. Vanuit SOx gezien is het van belang, dat duidelijk is op welke wijze de SOA beheerst wordt. 4.3.2 Impact van SOx voor SOA Vanuit SOx bekeken is SOA niets meer en niets minder dan een geheel van IT-componenten, die adequaat beheerst moeten worden. Als een organisatie strategisch kiest voor SOA en haar ITstrategie hier ook op afstemt, zullen de interne controlemaatregelen voor het plannen en organiseren van IT versterkt moeten worden. 4.3.3 Impact van SOx voor reconciliatie Een essentiële toevoeging van SOx voor de interne controle is dat het management niet alleen de bedrijfsprocessen zelf bewaakt, maar ook de processen bewaakt die de beheersing van processen verzorgen. Het reconciliatieproces is één van de beheersprocessen voor de financiële verslaglegging. Hiermee valt het reconciliatieproces onder de SOx wetgeving en wordt het reconciliatieproces een object van SOx audits. Het reconciliatieproces wordt ondersteund door informatiefuncties en/of applicaties. De IT auditor van het reconciliatieproces moet vaststellen op welke wijze wordt voldaan aan de SOx eisen voor deze informatiefuncties. De relatie tussen SOA en reconciliatie komt nadrukkelijk naar voren op het moment, dat de controle totalen moeten worden bepaald. De reconciliatievragen vanuit het financiële domein worden naar de basisadministratie gestuurd middels een request. Vervolgens komt de response met het antwoord dat gereconcilieerd kan worden met controletotalen uit de financiële administratie. 4.4
Interpretatie van CoP voor SOA en reconciliatie
4.4.1 Inleiding ISO 17799 Code of Practice for information security beschrijft de general IT controls, die gehanteerd moeten worden. Op basis van de inherente risico’s van SOA voor de volledigheid van de financiële verslaglegging zijn een aantal CoP beheersmaatregelen van groot belang. De IT auditor die een beoordeling maakt van het reconciliatie proces bij SOA moet zeker de volgende beheersmaatregelen in zijn/haar audit betrekken: •
10.1.4 Separation of environments 21
•
10.8.2 Exchange agreements
•
10.8.4 Electronic messaging
•
11.2.2 Privilege management
•
11.5.2 User identification and authentication
•
11.4.7 Network routing control
•
12.2.3 Message integrity
•
12.2.4 Output data validation
De norm om de beheersmaatregelen te toetsen moet specifiek worden gemaakt per audit. In de volgende paragrafen worden de CoP beheersmaatregelen uitgewerkt, zodat bij de risico’s van SOA voor de volledigheid worden gemitigeerd en daardoor minder reconciliatieverschillen optreden. 4.4.2 CoP 10.1.4 Separation of environments Deze beheersmaatregel is gericht om de productieomgeving alleen aan te passen via een gecontroleerd proces, waarbij de functiescheiding voor de automatiseringsorganisatie wordt gerealiseerd, zodat alleen geautoriseerde gebruikers toegang hebben tot de juiste omgeving. Hiermee wordt het risico beperkt, dat automatiseringsmedewerkers ongeautoriseerd, d.w.z. zonder goedkeuring van de verantwoordelijke functionele vertegenwoordiger, de ICT omgeving aanpassen. De IT organisatie en middelen bij de banken in Nederland zijn van een schaal, dat volledige scheiding van omgevingen verwacht mag worden. Het OTAP principe, d.w.z. scheiding tussen ontwikkel, test, acceptatie en productie is niet alleen van toepassing op de bedrijfsapplicaties, maar ook op de infrastructuur en operating software. Om reconciliatieverschillen te voorkomen moet bij de audit van SOA de scheiding van omgevingen worden beoordeeld voor: 1. OTAP voor reconciliatieprogrammatuur, zodat de controletotalen correct vergeleken worden; 2. OTAP voor message infrastructuur, zodat het upgraden van de message infrastructuur niet leidt tot het verliezen van messages; 3. OTAP voor applicatieprogrammatuur voor messages, zodat de verschillende omgevingen met elkaar kunnen blijven communiceren; 4. OTAP voor de diverse betrokken bedrijfsapplicaties, specifiek voor de programmatuur die de controletotalen bepalen. Deze scheiding van omgevingen moet nadrukkelijk tot uiting komen in de change procedure voor de verschillende componenten. 4.4.3 CoP 10.8.2 Exchange agreements Deze beheersmaatregel is gericht op de uitwisseling van gegevens met externe partijen. Bij grote financiële instellingen moeten deze ook tussen de verschillende domeinen worden opgesteld. Deze exchange agreements vormen de basis voor de autorisatie van services tussen de domeinen. Deze contracten kennen verschillende vormen, zoals productieafspraken en service level agreements. De IT auditor moet beoordelen of minimaal de volgende vragen zijn beantwoord: 1. Welke partijen wisselen gegevens uit en voor welke bedrijfsprocessen? Welke CIA rating is van toepassing op de gegevensuitwisseling? Welke beveiligingsprocedures zijn ingericht om de autorisaties voor de gegevensuitwisseling te autoriseren? Zijn de exchange agreements getekend door personen met de juiste bevoegdheid; 2. Welke operationele IT afdelingen realiseren de uitwisseling? En op welke wijze is het support hiervoor geregeld? Welke procedures, hulpmiddelen en application controls zijn ingericht om de gegevensstromen te volgen en verminking te voorkomen?
22
3. Wie is verantwoordelijk voor de beheersing en bevestiging van overdracht, verspreiding en ontvangst van de gegevens? Op welke wijze en met welke hulpmiddelen wordt dit gerealiseerd (XCOM, FTP, MQSeries, etc.)? Welke support procedures zijn ingericht om de inherente risico’s te mitigeren? 4. Welke technische eisen zijn geformuleerd? Welke standaards worden gehanteerd o.a. naamgevingconventies voor messages en attributen? Welke standaards worden gehanteerd voor het beschrijven van de gegevensuitwisseling (metadata)? Welke changeprocedure is ingericht om wijzigingen in de interface en metadata door te voeren? 5. Welke procedures worden gevolgd bij (security)incidenten, zodat voorkomen wordt dat bij (security)incidenten naar elkaar gewezen gaat worden? Zijn de taken, (onderzoek)verplichtingen en bevoegdheden duidelijk omschreven? Deze contracten hebben de doelstelling om te zorgen, dat de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens gewaarborgd is. Met SOA neemt het aantal contracten toe, aangezien meerdere partijen bij de gegevensuitwisseling betrokken kunnen zijn. 4.4.4 CoP 10.8.4 Electronic messaging Deze beheersmaatregel richt zich specifiek op de message uitwisseling. De beveiligingsmaatregelen voor de message-uitwisseling moeten minimaal de volgende zaken afdekken: 1. Borgen dat berichten alleen kunnen worden verstuurd en ontvangen door geauthenticeerde en geautoriseerde gebruikers. (vertrouwelijkheid) 2. Waarborgen dat de elektronische berichten correct worden geadresseerd. (integriteit) 3. Waarborgen dat de services voor de uitwisseling van berichten beschikbaar zijn. (beschikbaarheid). 4. Het wettelijk kader voor berichtenverkeer moet voldoende zijn gewaarborgd. Bij de internationale banken moeten ook de verschillen in de wetgeving tussen de verschillende landen in dit kader worden betrokken. Bijvoorbeeld de beperkingen voor het versleutelen van gegevens bij communicatie met de Verenigde Staten. (compliance) De IT auditor moet deze criteria toetsen, zodat de er zekerheid ontstaat dat de risico’s verbonden aan de berichtenuitwisseling zijn gemitigeerd. 4.4.5 CoP 11.2.2 Privilege management Deze maatregelen hebben de doelstelling om het toewijzen en gebruik van systeemrechten te beperken en te beheersen. Uitgangspunt is dat systeemrechten (privileges) alleen worden toegekend aan ICT beheerders en niet aan eindgebruikers. Het beheersen van de systeemrechten gebeurt door logische toegangsbeveiliging voor de ICTbeheerders. Met SOA moet hier een duidelijk onderscheid gemaakt worden tussen de rechten van ICT beheerders voor uitvoering van systeemservices en toegang tot de gegevens. Voor het privilege management moet de volgende maatregelen worden getroffen: 1. Logische toegangsbeveiliging voor de ICT beheerders voor de verschillende platform componenten. Met SOA wordt de message infrastructuur ingevoerd. De ICT beheerders mogen niet de mogelijkheid hebben om messages te versturen naar bedrijfsapplicaties. Er moet een duidelijke functiescheiding zijn tussen de ICT-beheerders van de message infrastructuur en de bedrijfsapplicaties. 2. De toegangsrechten moeten worden toegekend met het criterium ‘noodzakelijk voor het vervullen van de functie’ en alleen voor de periode dat dit vereist is voor de uitvoering van de taak. Deze richtlijn moet ook zijn vastgelegd in de autorisatieprocedure. 3. Een autorisatieproces moet zijn ingericht. Dit autorisatieproces moet borgen, dat alle verstrekte autorisaties worden vastgelegd.
23
4. Er moet zo min mogelijk gebruik worden gemaakt van de systeemrechten o.a. door het gebruik van de systeemcomponenten met deze rechten i.p.v. de rechten direct toe te kennen aan de gebruiker. 5. Er moet zo min mogelijk programmatuur worden ontwikkeld worden, die systeemrechten nodig hebben. 6. De systeemrechten moeten toegekend worden aan andere userids, dan die regulier worden gebruikt. Het gebruik van deze ‘speciale’ userids moeten gecontroleerd worden, zodat vastgesteld wordt dat er geen misbruik van is gemaakt. Het gebruik van systeemrechten geeft een verhoogd risico voor de vertrouwelijkheid, integriteit en beschikbaarheid en moet daarom tot een minimum worden beperkt. Het risico van systeemrechten voor het financiële domein is dat niet alle gegevens correct worden doorgegeven, waardoor de volledigheid van de financiële verantwoording niet gewaarborgd kan worden. 4.4.6 CoP 11.5.2 User identification and authentication Deze maatregel dwingt af dat alle gebruikers uniek zijn te identificeren en te authenticeren. De gebruikercode wordt toegewezen aan een natuurlijk persoon en mag alleen gebruikt worden door de betreffende persoon. De maatregel moet worden afgedwongen voor alle gebruikers van de geautomatiseerde systemen, dus eindgebruikers, maar ook ontwikkelaars, operators, netwerk administrators, DBAs, etc. De userid moet worden gebruikt voor het loggen van activiteiten door de gebruiker. Indien gebruikerscodes speciale (systeem)rechten hebben, dan moeten deze gebruikerscodes geen normale functies kunnen uitvoeren. Hiermee wordt voorkomen, dat de functiescheiding kan worden doorbroken door één gebruiker met twee gebruikercodes zonder dat dit zichtbaar is. Hierbij is het belangrijk om te onderkennen, dat één persoon dus meerdere gebruikerscodes kan hebben. Het gebruik van generieke userids voor muterende functies en vertrouwelijke gegevens, d.w.z. een userid die door meerdere personen wordt gebruikt, moet tot een minimum worden beperkt. Hierbij moeten aanvullende maatregelen worden getroffen, zodat bekend is wie wanneer over de gebruikerscode en het wachtwoord beschikte. 4.4.7 CoP 11.4.7 Network routing control Er moeten maatregelen worden getroffen om te verzekeren, dat de routering van berichten tussen de verschillende systemen en applicaties niet kan worden doorbroken en de getroffen beveiligingsmaatregelen niet kunnen worden doorbroken. Voor de reconciliatie met SOA is dit een essentiële maatregel, want het muteren van berichten c.q. het anders routeren van berichten kan leiden tot onverklaarbare verschillen. Dit betekent dat er controles moeten plaatsvinden op de ontvangst en verzendadressen, zodanig dat beide adressen bekend zijn en de betreffende berichten mogen uitwisselen volgens de autorisaties tussen services. Deze controle moet niet alleen plaatsvinden op infrastructureel niveau (machine-to-machine, network-to-network, point-to-point, message queue-to-message-queue), maar ook op service-toservice niveau en ook op bedrijfsproces niveau conform de exchange agreements. 4.4.8 CoP 12.2.3 Message integrity Deze maatregelen hebben als doelstelling om de integriteit van de individuele berichten te waarborgen. Voor banken met SOA is dit een essentiële voorwaarde, want het aanpassen van een bedrag in een message kan leiden tot ernstige financiële schade. Ook het muteren van een rekeningnummer kan leiden tot ernstige financiële schade. Effectief betekent dit dat de message integrity voor banken moet worden gecontroleerd bij de verzender en bij de ontvanger. Hierbij kan gebruik worden gemaakt van cryptografie en controletotalen, zodat mutaties in berichten direct aan het licht komen. Deze maatregelen moeten niet alleen getroffen worden voor communicatie met externe partijen, maar ook voor interne berichten van financiële aard.
24
4.4.9 CoP 12.2.4 Output data validation Deze maatregel is het fundament voor reconciliatie. De doelstelling van ‘Output data validation’ is om te controleren dat de opleverde informatie uit applicatie wordt gevalideerd en correct is. De volgende maatregelen moeten worden aangetroffen: 1. Plausibiliteitcontroles voor het testen dat de output binnen de verwachte bandbreedte is, reconciliatie tussen ex ante en ex post, indien dit vanuit het bedrijfsproces mogelijk is. 2. Reconciliatie van totaaltellingen om vast te stellen, dat alle gegevens zijn verwerkt. 3. Voorzien in voldoende informatie aan de eindgebruiker of het volgend verwerkende applicatie, zodat vastgesteld kan worden dat de gegevens juist zijn. 4. Procedures om de juistheid van de gegevensverwerking vast te stellen 5. Definiëren van taken, verantwoordelijkheden en bevoegdheden van alle medewerkers in het controle proces voor het gegevensuitvoer. 6. Opstellen van een audit trail voor de controle van de output. De toegenomen complexiteit van de infrastructuur en de applicaties met introductie van SOA leidt tot additionele controles op de volledige verwerking van de gegevens. Een adequaat ingerichte reconciliatie over de verschillende componenten van de infrastructuur en verschillende applicaties leidt tot adressering van bovenstaande punten. Adequate ‘output’ is essentieel voor de informatievoorziening t.b.v. bedrijfsprocessen. 4.5
Interpretatie van Clark & Wilson model voor SOA en reconciliatie
4.5.1 Theoretische uitgangspunten Clark & Wilson model Het Clark & Wilson model is een model dat zich richt op bedrijfsmatige omgevingen, waar de integriteit van informatie belangrijker is dan de vertrouwelijkheid van informatie. Het Clark en Wilson model biedt een concept voor de waarborging van de integriteit voor objectgeoriënteerde omgevingen. Clark & Wilson onderkennen een aantal stappen om te komen tot applicaties, die de gegevens integer verwerken: Stap 1 Ontwerp en bouw van applicaties volgens een aantal gedefinieerde regels (certificering en handhavingregels) voor het afdwingen van de integriteit. Deze regels worden hieronder toegelicht. Stap 2 Certificeer de applicaties door een onafhankelijke instantie, voordat deze ter beschikking gesteld worden aan eindgebruikers. Dit certificeringproces gebeurt door applicaties (services) te toetsen aan certificering- en handhavingregels. Het proces om dit te realiseren is geborgd in het configuratie- en change-proces. Deze processen moeten zodanig zijn ingericht dat de scheiding tussen ontwikkel-, test-, acceptatie- en productieomgeving is gewaarborgd door functiescheiding in de change organisatie. Stap 3 Autoriseer eindgebruikers conform de ontworpen autorisatie matrix, waardoor de functiescheiding wordt gewaarborgd. Voor het aanbrengen van de autorisatie moet ook een functiescheiding worden aangebracht, zodanig dat er niemand is die zichzelf autorisaties kan toekennen en ook de applicaties kan uitvoeren. Clark & Wilson onderkennen in hun conceptuele model een aantal uitgangspunten voor betrouwbare applicaties: 1. Het systeem moet beschikken over een identificatie- en authenticatiemechanisme. Een procedure mag alleen uitgevoerd worden door een geautoriseerde gebruiker, waarbij moet worden afgedwongen dat het systeem deze autorisatiecontrole uitvoert. Deze systematiek is bijvoorbeeld geïmplementeerd binnen het ERP-pakket SAP en bankpakket Globus. 2. Het systeem moet iedere gebruiker autoriseren voor een set programma’s conform de ontworpen AO/IC inrichting en functiescheiding. Voor het toekennen van de set programma’s in Service Oriented Architecture kan de opzet van role-based access control (RBAC) worden gehanteerd. Hierbij is het van belang, dat er onderscheid gemaakt wordt
25
tussen de functies op een object en de data afhankelijke autorisaties die afhankelijk zijn van limieten op een object. Voorbeeld Medewerker X mag Hypotheken accepteren (status mutatie) tot een bedrag van € 500.000,-. De service Hypotheken accepteren wordt aangeroepen, waarna gecontroleerd wordt of medewerker X de functie Hypotheken accepteren mag uitvoeren (RBAC) en vervolgens wordt gecontroleerd of het hypotheekbedrag de autorisatie niet te boven gaat. 3. Er is een strikte scheiding tussen Integriteit Verificatie Procedures (IVP) en Transformatie Procedures (TP) voor een object of groep objecten (O). 4. De gegevens in het systeem mogen alleen gewijzigd worden door een beperkte set transformatieprocedures die voldoen aan gespecificeerde integriteitregels. De transformatieprocedures worden in SOA vertaald naar entity centric services. Voorbeeld: Het object Hypotheek wordt bij een aflossing gemuteerd, doordat het openstaand saldo wordt verlaagd, maar ook het object aflossing wordt bijgewerkt. Beide objecten moeten in een integere situatie worden achtergelaten. 5. De transformatie procedures zorgen dat gegevens zodanig worden toegevoegd of gemuteerd, dat alle informatie wordt weggeschreven, en wel zodanig dat achteraf de aard van de uitgevoerde transactie kan worden geconstrueerd; Voorbeeld:Als het object Hypotheek wordt bijwerkt, wordt een nieuw record toegevoegd met een nieuwe datum en het actuele openstaand saldo. Bij de Hypotheek worden gegevens vastgelegd over de gebruiker, transactiecode en timestamp. In de Service Oriented architecture moeten hier additionele gegevens bijkomen over de message, die de mutatie heeft veroorzaakt. Dit kan o.a. de SOAP-header zijn. In het reconciliatieproces kan vervolgens gecontroleerd worden dat de betreffende transacties conform de autorisatie matrix is gewijzigd. 6. Het systeem moet vastleggen welke gebruiker welke programma’s heeft aangeroepen, waarbij niet alleen de direct aangeroepen programma’s worden vastgelegd, maar ook de indirect aangeroepen programma’s. Voordat de aanroep wordt uitgevoerd moet gecontroleerd worden, dat de betreffende gebruiker is geautoriseerd om het programma uit te voeren. In de monitoring van de beveiliging kan hiermee geautomatiseerd gecontroleerd worden dat de functiescheiding niet is doorbroken. Om deze uitgangspunten hanteerbaar te maken hebben Clark & Wilson een aantal certificatieregels gedefinieerd voor integriteitverificatie- en transformatieprocedures: C1 –
Integriteitprocedures moeten vaststellen dat een object in een integere status is.
C2 –
Alle transformatieprocedures moeten zorgen dat, na de mutatie van een object, het object weer in een integere status achterlaat.
C3 –
Alle transformatie- en integriteitprocedures moeten getoetst worden aan de functiescheiding die ontleent is aan het AO/IC ontwerp, zodanig dat de functiescheiding niet kan worden doorbroken.
C4 –
Alle transformatieprocedures moeten alle noodzakelijke informatie wegschrijven, waarmee achteraf gereconstrueerd kan worden wat de aard van de uitgevoerde transactie is geweest.
C5 –
Alle transformatieprocedures moeten, als zij ongecontroleerde invoer verwerken, zorgen dat er alleen valide transformaties worden uitgevoerd, die zorgen dat de vastlegging van de data voldoet aan de integriteitregels van het betreffende object.
Naast de certificeringregels moeten applicaties ook voldoen aan een aantal handhavingregels: E1 –
Objecten mogen alleen door transformatieprocedures worden gemuteerd, waarvan getoetst is dat de betreffende transformatieprocedures het object in een integere status achterlaat.
26
E2 –
Het systeem moet een autorisatiematrix bevatten, waarin de transformatieprocedures zijn gekoppeld aan gebruikers volgens de ontworpen functiescheiding.
E3 –
Het systeem moet de identiteit bepalen van elke gebruiker, die een transformatieprocedure probeert uit te voeren.
E4 –
Alleen medewerkers die integriteitverificatie- en transformatieprocedures certificeren mogen de relatie tussen enerzijds gecertificeerde transformatieprocedures en gegevens, en anderzijds tussen transformatieprocedures en gebruikers leggen. Hierbij wordt opgemerkt, dat hiervoor wel een functiescheiding moet worden aangebracht tussen degene die de relatie legt (security officer = uitvoerende rol in autorisatieproces) en degene die deze relaties goedkeurt (de controllers die ook eigenaar van de applicatie zijn = beschikkende rol in autorisatieproces). In het Clark & Wilson conceptueel model wordt deze maatregel niet genoemd, maar in de service oriented architecture uitwerkingen wel. Deze functiescheiding wordt vastgelegd in servicecontracten, zodat de eigenaar van objecten (of objectelementen) in de gelegenheid is de beveiliging van zijn objecten te bewaken.
Deze regels bieden een kader voor het ontwerp en realisatie van services, die gebruikt worden binnen de Service Oriented Architecture, zodat de functiescheiding niet wordt doorbroken en de gegevens adequaat worden beveiligd. 4.5.2 Evaluatie van het Clark & Wilson model voor SOA en reconciliatie In het Clark & Wilson model wordt expliciet aandacht geschonken aan de functie van de transformatieprocedures, die de integriteit van gegevens waarborgen. De structuur van SOA met de diverse service lagen is hiermee vergelijkbaar. De process centric services, task centric services en application services zijn van de categorie integriteitprocedures en de entity centric services van de categorie transformatieprocedures. Door deze categorie-indeling en de eisen van het Clark & Wilson model is de conclusie dat het autorisatie mechanisme gevalideerd moet worden in de entity centric services. Hieruit blijkt dat alleen de entity centric services in staat zijn om de gegevens op te leveren voor het reconciliatiesysteem. De gegevens worden via task centric services beschikbaar gesteld aan het reconciliatiesysteem. Hiervoor kunnen een aantal richtlijnen worden afgeleid die moeten worden aangetroffen door de IT auditor bij de audit van een applicatie onder SOA: 1. De architectuur van de applicaties moeten de entity centric services (object georiënteerd) duidelijk isoleren van de overige services; 2. De entity centric services moeten bewaken, dat de autorisatieregels niet worden doorbroken; 3. De entity centric services moeten functies bevatten om de reconciliatievragen te kunnen beantwoorden, die door task centric services worden gesteld. 4. De IT auditor moet beoordelen of de entity centric services de gegevens in een integere status vastleggen. 5. Als er meerdere entiteiten bij een entity centric service zijn betrokken moet de IT auditor beoordelen op welke wijze de integrale set van entiteiten in een integere status wordt achtergelaten. Hierbij speelt de wijze waarop de foutafhandeling is gerealiseerd een belangrijke rol, want als er een fout optreedt moet er gezorgd worden dat er weer een integere situatie ontstaat (rollback) en moeten de mutaties integraal definitief worden gemaakt (commit).
27
5 5.1
Risico’s en beheersmaatregelen voor reconciliatie bij SOA Inleiding
Dit hoofdstuk beschrijft de context van de beheersmaatregelen voor reconciliatie bij SOA voor het aantonen van de volledigheid van de financiële verslaglegging bij banken a.d.h.v. de risico’s. Hierbij wordt onderscheid gemaakt tussen: 1. de generieke AO/IC (hoofdstuk 5); 2. de General IT controls (hoofdstuk 6); 3. de AO/IC speficiek voor de reconciliatie (hoofdstuk 7). De beheersmaatregelen voor de reconciliatie kunnen worden ingedeeld op basis van het onderstaande model. AO/IC maatregelen General IT controls Reconciliatie applicatie Operationele applicaties
Financiële applicatie suite MA rapportage FA rapportage Grootboek
DWH
ETL/ Rules engine Ontvangstomgeving Message infrastructure Netwerk infrastructure Hardware infrastructure
5.2
Risico’s en beheersmaatregelen voor AO/IC voor reconciliatie bij SOA
5.2.1 Functiescheiding Een krachtige interne controle maatregel is functiescheiding. De functiescheiding wordt bij banken gerealiseerd door logische toegangsbeveiliging op omgevingen (DTAP) en applicaties (vaak middels RBAC). De SOA architectuur leidt ertoe, dat op de business process layer functies worden toegekend aan eindgebruikers, waarna een reeks van services wordt aangeroepen. De functiescheiding wordt hiermee op business process layer gerealiseerd. Vanuit de business process layer worden de overige services aangeroepen, waarbij voor de informatiebeveiliging de entity services het voornaamst zijn. Een risico dat bij SOA bestaat is dat de functiescheiding wordt doorbroken, doordat een eindgebruiker autorisatie krijgt voor entity service vanuit twee verschillende business proces services en deze autorisaties worden opgeteld. Hierdoor krijgt de eindgebruiker per saldo te veel autorisaties, waarbij met business process functie A en de autorisatie van entity service B er feitelijk mutaties gerealiseerd kunnen worden, die volgens de AO/IC niet mogelijk moeten zijn. Het doorbreken van de functiescheiding kan een foutieve financiële verslaglegging tot gevolg hebben, doordat mutaties ongedaan worden gemaakt zonder dat dit zichtbaar is. De controle op het adequaat werken van de functiescheiding versterkt het vertrouwen in de juistheid van de financiële gegevens. Aangevuld met de ‘onafhankelijke’ vaststelling door de controller zorgt ervoor dat er sterker op de functiescheiding kan worden gesteund.
28
5.2.2 Directierichtlijnen In de moderne geautomatiseerde omgeving voor de bank zijn er twee geautomatiseerde componenten, namelijk workflow management en business rules engine, die gebruikt worden om de dynamische structuur van SOA te implementeren. De processen worden met een formele procestaal, bijv. BPEL beschreven. Workflow management en business rules engines interpreteren de betreffende proces taal en sturen de diverse services aan. Het workflow management beïnvloedt op welke wijze mutaties door de verschillende applicaties worden geloodst. Hiermee wordt ook gerealiseerd, dat de juiste processtappen worden doorlopen. De business rules engine beïnvloedt de geautomatiseerde beslissingen door de diverse services. In deze business rules worden ook de ‘straight through processing’ regels gedefinieerd, waaronder de beslissingen om specifieke autorisaties of het vier-ogen-principe toe te passen bij het overschrijden van directierichtlijnen. Bij audit van het financiële domein moet de opzet van de business rules engines worden beoordeeld. Daarnaast moet beoordeeld worden of het workflow management correct is. Hierbij moet ook vastgesteld worden dat de inrichting van de business rules engine en workflow volgens adequate (change)procedures wordt aangepast. Als deze processen niet adequaat zijn ingericht, kunnen directierichtlijnen worden omzeild en wordt niet de juiste validatie uitgevoerd of de juiste AO/IC procedure gevolgd. Met de operationele reconciliatie kan achteraf worden vastgesteld of de juiste controles zijn uitgevoerd en de directierichtlijnen correct zijn toegepast. Hiervoor moet het workflow management systeem en de business rules engine wel een volledige audit-trail vastleggen. In de reconciliatie kan vervolgens gecontroleerd worden door te valideren dat alle contracten en mutaties met een hogere waarde dan ‘x’ door het autorisatieproces met hogere limieten zijn gecontroleerd. Het workflow management en de business rules engine wordt in het algemeen (functioneel) beheerd door de operationele afdelingen. De controller kan met de proces georiënteerde reconciliatie toch de correcte toepassing van de directierichtlijnen controleren. De directie realiseert hiermee een sterkere functiescheiding, want de controle op de directierichtlijnen wordt buiten de operationele afdeling gebracht zonder dat de controller elk operationeel proces moet testen. Hierdoor kan de financiële verslaglegging sterker steunen op de juiste werking van de functiescheiding. 5.3
Risico’s applicaties met SOA
5.3.1 Inleiding De implementatie van SOA introduceert een aantal informatiebeveiligingrisico’s. Deze risico’s ontstaan impliciet door de veranderde applicatiestructuur door het gebruik van services. De volgende risico’s kunnen worden onderkend: •
De autorisatiematrix houdt alleen rekening met het business process service niveau en niet met de services op een lager niveau;
•
De autorisatiematrix houdt geen rekening met de gegevens;
•
De autorisatiematrix heeft geen of onvolledige relatie met de service agreements voor applicatieservices;
•
Onbeheersbare autorisatiematrix door hoeveelheid services
•
Entity services kunnen vanuit diverse services worden aangeroepen, waardoor mogelijk een functie wordt gestart, waarvoor de betreffende gebruiker niet is geautoriseerd. Hoe wordt identificatie, authenticatie en autorisatie afgeregeld door de entity services?
•
Binnen SOA is het mogelijk dat een applicatie zich voordoet alsof hij een andere service is, waardoor de betreffende gebruiker ongeautoriseerde transacties kan uitvoeren.
5.3.2 Risico’s informatiebeveiliging verbonden aan de inrichting van de autorisatiematrix Als de autorisatiematrix alleen rekening houdt met de business process services is het risico, dat eindgebruikers onbedoeld te veel autorisatie krijgen, doordat er op een lager service niveau een conflict ontstaat, waardoor de beoogde functiescheiding wordt doorbroken. Verder geldt dat
29
services niet alleen aangeroepen worden door eindgebruikers, maar ook geautomatiseerd. Ook dan moeten de juiste autorisatieregels worden toegepast. Als de autorisatiematrix geen rekening houdt met de gegevensstructuren op een lager niveau is het risico aanwezig, dat een gebruiker bredere rechten krijgt dan bedoeld. Vanuit SOA en analoog aan het Clark & Wilson model moet de IT auditor kritisch beoordelen in welke mate de autorisatiecontrole op het juiste plaats is belegd en correct is gemodelleerd. Voor deze autorisatie is het van belang om te realiseren, dat er geen beperkingen zijn om vanuit een business process service een entity service aan te roepen. Als op entity service niveau dan standaard een autorisatiecontrole functie wordt gedefinieerd kan de autorisatiecontrole zeer efficiënt worden gerealiseerd met inachtneming van de Clark & Wilson regels. In de autorisatiematrix moet de service agreement informatie vastgelegd zijn, zodat services elkaar alleen kunnen aanroepen als hier een agreement voor aanwezig is. Door de organisatie moet worden overwogen op welke wijze deze agreements worden vastgelegd en goedkeuring voor de agreements wordt gegeven. Deze goedkeuringsprocedure moet ook bepalen op welke wijze de autorisatiematrix wordt bijgewerkt. Het detailniveau van de service agreement beïnvloedt het detailniveau van de autorisatiematrix. Om de autorisatiematrix beheersbaar te houden, zullen rollen moeten worden vastgesteld, want een te uitgebreide autorisatiematrix vormt een risico op zich. Hierom moet bij het ontwerpen van de applicatie met SOA het streven zijn om zo veel mogelijk services ongeautoriseerd te kunnen uitvoeren. De autorisatiecontroles moeten alleen op de kritische componenten worden toegepast. Alleen hierdoor kan de beoogde flexibiliteit worden bereikt zonder dat de autorisatie kan worden doorbroken. De IT auditor moet beoordelen in hoeverre dit principe wordt opgevolgd. In hoofdstuk 6 wordt de relatie gelegd tussen de General IT controls uit het hoofdstuk 4 en opzet, bestaan en werking voor de financiële verslaglegging. 5.3.3 Risico’s voor de informatiebeveiliging vanuit services Conform de regels van het Clark & Wilson model moeten de entity services zorgen voor adequate authenticatie en identificatie van de gebruiker en/of de service waardoor zij worden aangeroepen. De entity service moet voor elke actie controleren of de betreffende aanroep in lijn is met autorisatiematrix. Als deze controle niet adequaat wordt uitgevoerd is het risico dat een gebruiker ongeautoriseerd gegevens muteert. Het vaststellen van de authenticatie en identificatie kan een complexe stap zijn. Bij de ontwikkeling van SOA wordt gebruik gemaakt van ‘sessiegeheugen’, waarin de relevante gegevens staan die de entity service kan ophalen voor de controle van de identificatie en authenticatie. De communicatie tussen de services wordt hiermee gereduceerd tot de sessiesleutel, zodat de communicatie in hoge mate is gestandaardiseerd. Een ander risico dat zich voordoet bij SOA is ‘claiming’, waarbij een service zich voordoet als een andere service. Deze situatie kan zich al dan niet bewust voordoen als bij de opzet van de service de identificatie in de programmatuur van de services wordt gerealiseerd of meegegeven wordt in de service message en deze gebruikt wordt voor identificatie. De IT auditor moet vaststellen, dat een correct mechanisme wordt gehanteerd voor de identificatie en ‘claiming’ niet mogelijk is. Dit mechanisme is onderdeel van de controle op de General IT controls.
30
6 6.1
General IT controls voor reconciliatie bij SOA Inleiding
Rapporteren
Grootboek
Datawarehouse
ETL
Rules engine
Staging area
Basisadministraties
Message infrastructuur
Netwerk infrastructuur
Hardware
IT componenten
Door de hoge automatiseringsgraad van de financiële verslaglegging bij banken kan deze alleen betrouwbaar zijn als zij op sterke IT beheersmaatregelen kan steunen. Dit hoofdstuk beschrijft de aspecten, die de IT auditor moet controleren om een oordeel te kunnen vormen over de reconciliatie, waarbij aangesloten wordt op hoofdstuk 4 Wettelijk en theoretisch kader, en dan met name CoP en Clark & Wilson. In hoofdstuk 4 zijn de inhoudelijke normen beschreven. In dit hoofdstuk wordt beschreven op welke wijze de inhoudelijke norm gecontroleerd wordt.
Beheersmaatregelen CoP Controls 10.1.4 Separation of environments 10.8.2 Exchange agreements 10.8.4 Electronic messaging 11.2.2 Privilege management 11.5.2 User identification and authentication 11.4.7 Network routing control 12.2.3 Message integrity 12.2.4 Output data validation Application controls vanuit Clark & Wilson Certificatieregels Integriteitsprocedures controleren integriteit Transformatieprocedures laten object in integere status achter Transformatieprocedures implementeren functiescheiding Transformatieprocedures schrijven volledige audittrail Transformatieprocedures voeren alleen valide transformaties uit Handhavingsregels Transformatieprocedures zijn getest op certificatieregels Applicaties bevatten autorisatiematrix, die overkomt met ontworpen AO Identiteit van elke gebruiker wordt bepaald Functiescheiding bij autorisatieproces tussen eigenaar en security officer = verplicht te beoordelen = wenselijk te beoordelen
Voor de oordeelsvorming zal de IT auditor eerst de opzet van de IT beheersmaatregelen beoordelen. Indien de opzet als adequaat wordt beoordeeld, wordt het bestaan beoordeeld en tenslotte wordt de werking beoordeeld. 6.2
CoP 10.1.4 Separation of environments
6.2.1 Opzet Voor beoordeling van de scheiding van omgevingen moet de IT auditor beoordelen welke opzet is gekozen voor de verschillende componenten. De ICT voor de financiële verslaglegging moet volledig volgens het OTAP principe worden ingericht. De IT auditor moet opzet van de functiescheiding tussen de verschillende omgevingen beoordelen en controleren, dat met de logische toegangsbeveiliging voor gebruikers en automatiseringsmedewerkers de scheiding van omgevingen niet wordt doorbroken. Verder moet de opzet beoordeeld van de wijze, waarop (systeem)software gecontroleerd gemigreerd wordt van ontwikkel (O) via test (T) en acceptatie (A) naar productie (P). Dit proces moet nadrukkelijk tot uiting komen in de change procedure voor de verschillende componenten. 6.2.2 Bestaan Het bestaan van de scheiding van omgevingen begint met de controle dat voor de verschillende componenten ook de verschillende OTAP omgevingen bestaan. Daarnaast moet er gecontroleerd worden, dat verstrekte autorisaties overeenkomstig de opzet van functiescheiding zijn.
31
Er moet ook beoordeeld worden in hoeverre de software conform de change-procedure in productie is gegeven. De IT auditor voert een controle op een change uit en valideert of de betreffende procedure is gevolgd en de bijbehorende documentatie en software correct is aangetroffen. Tenslotte beoordeelt de auditor of bij nieuwe/ gewijzigde autorisatieaanvragen gecontroleerd wordt, dat de functiescheiding niet wordt doorbroken. 6.2.3 Werking De werking wordt beoordeeld door het vergelijken van de verschillende omgevingen en te controleren, dat er in productie (P) geen nieuwere software staat dan in respectievelijk de voorliggende omgevingen (A, T en O). Daarnaast wordt een steekproef uit de changes genomen en beoordeeld of de change procedure correct is gevolgd. Tenslotte wordt gecontroleerd of de functiescheiding is doorbroken op basis van de logische toegangsbeveiliging en AO/ICbeschrijving. Dit kan door een steekproef van medewerkers of alle medewerkers als geautomatiseerde controle mogelijk is. 6.3
CoP 10.8.2 Exchange agreements
6.3.1 Opzet Voor de opzet van exchange agreements wordt beoordeeld of er een procedure is voor het opstellen en gebruiken. De procedure wordt gecontroleerd op de eisen van een exchange agreement (zie voor eisen paragraaf 4.4.3.) en er wordt gecontroleerd dat de procedure aansluit op de organisatorische inrichting van de IT-afdelingen en gebruikersafdelingen. Verder wordt ook beoordeeld dat de procedure aansluit op de autorisatieprocedures, want de exchange agreement leidt op systeemniveau tot autorisaties. 6.3.2 Bestaan Het bestaan van exchange agreements wordt gecontroleerd door een lijncontrole uit te voeren voor de procedure en te controleren, dat alle stappen zijn uitgevoerd en uiteindelijk resulteren in een adequaat geadministreerde ‘exchange agreement’ en tot de juiste autorisaties. 6.3.3 Werking De werking van de procedure voor exchange agreements wordt gecontroleerd door een steekproef te nemen uit de exchange agreements (eventueel aanvullend kiezen voor gewijzigde of nieuwe, als deze geen onderdeel uitmaken van de steekproef!). Vervolgens wordt gecontroleerd of de inhoud van de exchange agreements klopt en de bijbehorende autorisaties ook correct zijn verleend. 6.4
CoP 10.8.4 Electronic messaging
6.4.1 Opzet Bij de beoordeling van de opzet voor electronic messaging wordt bekeken op welke wijze de organisatie wil zorgen, dat berichten alleen kunnen worden verstuurd en ontvangen door geauthenticeerde en geautoriseerde gebruikers (vertrouwelijkheid); waarborgen dat de elektronische berichten correct worden geadresseerd. (integriteit); waarborgen dat de services voor de uitwisseling van berichten beschikbaar zijn (beschikbaarheid). Hiervoor moet het ontwerp van de message infrastructuur worden beoordeeld. 6.4.2 Bestaan Het bestaan van de correcte opzet van electronic messaging wordt gedaan door vanuit een financieel rapport de keten te volgen tot en met de basisadministratie en telkens als er overdracht van een message plaatsvindt te beoordelen of aan bovengestelde eisen is voldaan. 6.4.3 Werking De correcte werking van de beheersmaatregelen wordt aangetoond door een steekproef te nemen van messages en te controleren dat de verwerking voldoet aan bovenstaande voorwaarden. Hierbij moet de samenstelling van de steekproef worden gebaseerd op de verschillende messagestromen en het steekproef aantal binnen de verschillende message-stromen worden bepaald. Daarnaast moet de IT auditor de verstrekte autorisaties aan de verschillende services controleren t.o.v. de verstrekte gegevens.
32
6.5
CoP 11.2.2 Privilege management
6.5.1 Opzet De IT auditor moet beoordelen op welke wijze systeemrechten (privileges) worden toegekend. De opzet van deze toekenning moet zodanig zijn, dat aan de eisen uit paragraaf 4.4.5 wordt voldaan. Hiervoor moet minimaal de procedure voor het toekennen van deze autorisaties zijn beschreven. Hierbij toetst de IT auditor of de procedure aansluit bij de organisatorische inrichting. 6.5.2 Bestaan De IT auditor controleert m.b.v. een lijncontrole, dat de procedure voor het verstrekken en gebruiken van systeemrechten correct is. Hierbij wordt aansluiting gezocht tussen de verstrekte autorisaties en de audittrail die bij het verstrekken van deze autorisaties plaatsvindt. 6.5.3 Werking Voor het toetsen of de procedure voor het privilege management werkt, moet de IT auditor een steekproef nemen uit de audittrail van de te controleren periode, zodat bepaald kan worden welke autorisaties aangetroffen moeten worden in de administratie. 6.6
CoP 11.5.2 User identification and authentication
6.6.1 Opzet De opzet van de user identificatie, authenticatie en autorisatie moet bij SOA nadrukkelijk worden gesplitst in de maatregelen voor eindgebruikers en maatregelen voor services. De opzet van de identificatie, authenticatie en identificatie wordt gecontroleerd door de opzet van de security administratie te beoordelen met bijbehorende autorisatie procedures. Hierbij wordt gecontroleerd of alle organisatorische functies zijn onderkend, de applicatiefuncties zijn onderkend en er een autorisatiematrix is opgezet conform de functiescheiding uit de AO/IC. In deze autorisatiematrix moet staan beschreven welke applicatiefuncties wel en niet mogen worden gecombineerd. Hierbij kan gekozen worden om de autorisatie via rollen te definiëren (RBAC). De opzet voor de autorisatie van services moet aansluiten bij de message exchange agreements, die de basis vormen voor het autoriseren van service-to-service contacten. Bij de opzet beoordeelt de IT auditor of de aansluiting correct is gerealiseerd. Daarnaast beoordeelt de IT auditor of het autorisatiemechanisme correct is gerealiseerd in de verschillende services. 6.6.2 Bestaan Voor het bestaan van de identificatie, authenticatie en autorisatie beoordeelt de IT auditor de security administratie voor de verschillende componenten. Hierbij controleert de IT auditor met een lijncontrole of de autorisatieprocedures uit de opzet zijn gevolgd. Daarnaast controleert de IT auditor of de ontworpen autorisatiematrix ook als zodanig is geïmplementeerd. Ook voor de services controleert de IT auditor of de autorisatieprocedures zijn gevolgd door een lijncontrole voor het autoriseren van een service. Hierbij beoordeelt de IT auditor of de afspraken genoemd in de message exchange agreements ook correct zijn vastgelegd in de security administratie. 6.6.3 Werking De werking van de identificatie, authenticatie en autorisatie beoordeelt de IT auditor door een steekproef te nemen uit de autorisatie aanvragen. De omvang van de steekproef wordt bepaald op basis van het aantal mutaties of het totaal aantal verstrekte autorisaties. Deze autorisaties worden vervolgens inhoudelijk beoordeeld en getoetst aan de autorisatiematrix. Op basis van de resultaten stelt de IT auditor de bevinden op. 6.7
CoP 11.4.7 Network routing control en Cop 12.2.3 Message integrity
6.7.1 Opzet Er moeten maatregelen worden getroffen om te verzekeren, dat de routering van berichten tussen de verschillende systemen en applicaties niet kan worden doorbroken en de getroffen beveiligingsmaatregelen niet kunnen worden doorbroken. De opzet wordt beoordeeld a.d.h.v. architectuur overzichten, waarin beschreven staat op welke wijze dit plaatsvindt. De IT auditor beoordeelt ook de richtlijnen voor de opzet van het berichtenverkeer.
33
6.7.2 Bestaan De IT auditor controleert de adequate routing door te controleren of de routeringtabellen bestaan en overeenkomstig de opzet zijn. Voor de message infrastructuur betekent dit concreet, dat de ontworpen message flows daadwerkelijk aangetroffen worden in de omgeving. 6.7.3 Werking De IT auditor beoordeelt de werking a.d.h.v. de rapportages uit de routering, waarbij de verschillende message flows worden gecontroleerd op basis van steekproeven. De steekproef wordt bepaald op basis van het aantal messages. De IT auditor moet specifieke aandacht schenken aan de uitzonderingen en/of foute messages. De routering wordt gecontroleerd door op basis van de bron te bepalen welke messages door de bronnen verstuurd zijn naar de verschillende bestemmingen. De IT auditor controleert in de rapportage van de ontvanger dat dezelfde aantallen zijn ontvangen. Daarnaast controleert de IT auditor een steekproef van messages en controleert dat deze afzonderlijke messages ook verzonden en ontvangen zijn. 6.8
Applicatieve beheersmaatregelen op basis van Clark & Wilson
6.8.1 Opzet De opzet van de applicatieve controlemaatregelen wordt gecontroleerd op basis van de algemene richtlijnen voor het ontwerpen van applicaties en het feitelijke ontwerp van de applicaties. De IT auditor controleert of de Clark & Wilson richtlijnen verwerkt zijn in de applicatieopzet. De Clark & Wilson zijn slechts een beperkt aantal richtlijnen op hoofdlijnen. Het voornaamste is dat de IT auditor vaststelt, dat de gekozen normen dezelfde waarborgen bieden. 6.8.2 Bestaan Het bestaan van de applicatieve controlemaatregelen gebeurt door op basis van het ontwerp naar de applicatie te kijken en te beoordelen of deze eisen, daadwerkelijk in de applicatie zijn verwerkt. 6.8.3 Werking De werking van de applicatieve controlemaatregelen gebeurt door de audittrail te beoordelen en een gegevensanalyse uit te voeren. Hierbij wordt steekproefsgewijs bepaald of de verwerking heeft plaatsgevonden conform de applicatieve controlemaatregelen. Een krachtig middels hierbij is om met data analyse hulpmiddelen de voorkomende waarden te bepalen. Deze inhoudelijke waarden worden vervolgens vergeleken met de toegelaten waarden uit de opzet. Indien een gegevensanalyse niet mogelijk is, kan de IT auditor een steekproef nemen en de inhoudelijke gegevens van deze steekproef vergelijken met de toegelaten waarden uit de opzet. De IT auditor heeft daarnaast de mogelijkheid om de testresultaten van de applicatie te beoordelen. Uit deze testresultaten moet blijken dat de positieve en negatieve controles zijn getest. Een nadeel van deze testverslagen is, dat dit slechts een momentopname is en er in het verleden alsnog afwijkende gegevens kunnen zijn vastgelegd. Op basis van het gegevensonderzoek en de testresultaten kan de IT auditor de bevindingen opstellen en een oordeel vormen.
34
7 7.1
Reconciliatie voor de financiële verslaglegging Inleiding
Reconciliatie informatie
Verzekeringsrisico rapportage
Credit risk rapportage
Market risk rapportage
MA rapportage
FA rapportage
Grootboek
Financieel datawarehouse
Rules engine
Staging area
Basisadministraties
Naar
Dit hoofdstuk beschrijft de eisen voor de controletotalen voor de reconciliatie, die gerealiseerd moeten worden. De reconciliatie applicatie wordt beschouwd als een aparte applicatie.
Van Basisadministraties Staging area Rules engine Financieel datawarehouse Grootboek FA Rapportage MA Rapportage Market risk rapportage Krediet risico rapportage Verzekeringsrisico rapportage Reconciliatie informatiesysteem = verplicht te beoordelen = wenselijk te beoordelen
De bovenstaande tabel benadrukt de verbanden die de IT auditor moet controleren om een oordeel te kunnen vormen over de effectiviteit en efficiency van het reconciliatieproces. 7.2
Eisen informatiebeveiliging voor reconciliatie applicatie
De reconciliatie applicatie is een SOx kritische applicatie, d.w.z. moet voldoen aan alle SOx eisen doordat de applicatie wordt gebruikt voor het aantonen van de volledigheid van de financiële rapportage. De logische toegang tot de reconciliatie applicatie moet gelijkwaardig met de toegang tot het grootboek worden ingericht. De informatie uit het grootboek wordt namelijk op geaggregeerd niveau in de reconciliatieapplicatie vastgelegd. Het grootboek heeft de hoogste CIA-rating van de applicaties gerelateerd aan de financiële verslaglegging en geldt daarom als norm voor de reconciliatie applicatie. De IT auditor moet vaststellen, dat de opzet, bestaan en werking van de logische toegang voor de reconciliatieapplicatie voldoet aan de normen van de organisatie. De medewerkers die toegang hebben tot de reconciliatie applicatie moeten worden gezien als ‘insiders’ die toegang hebben tot de financiële resultaten met het risico van voorkennis. Hierdoor moeten er aanvullende geheimhoudingscondities worden gesteld aan de arbeidsvoorwaarden voor de betreffende medewerkers, zodat o.a. handel met voorkennis wordt voorkomen. De activiteiten door gebruikers en services in de reconciliatie applicatie moeten vastgelegd worden in een audit trail, zodat achteraf kan worden vastgesteld wie welke reconciliatie actie heeft uitgevoerd. 7.3
Reconciliatie IT controletotalen
Conform het reconciliatieproces moeten allereerst de IT controletotalen worden gecontroleerd. De IT controletotalen zijn gericht op het vaststellen, dat de technische verwerking correct verlopen is. Bij bestandsverwerkingen betekent dit dat er een voorlooprecord en sluitrecord is. In het voorlooprecord worden gegevens vastgelegd, waarmee vastgesteld kan worden dat het betreffende bestand verwerkt mag worden, bijvoorbeeld het bestand bevat gegevens van de juiste datum. In het sluitrecord worden gegevens vastgelegd, waarmee vastgesteld kan worden, dat het bestand volledig is en volledig verwerkt is, bijvoorbeeld aantal records en totaalbedrag van de mutaties debet en credit.
35
Bij SOA voldoet deze controle op bestanden niet meer, want de messages worden afzonderlijk aangeleverd. Bij SOA worden de messages in het algemeen asynchroon afgeleverd. Dit betekent dat er niet gegarandeerd kan wordt dat messages in dezelfde volgorde ontvangen worden dan dat ze verzonden zijn. Op het moment dat de financiële verwerking start, moet bekend zijn dat de operationele systemen hun gegevens volledig hebben aangeleverd voor de mutatieperiode. In de volgende paragraaf wordt het begrip mutatieperiode nader toegelicht. De asynchrone aanlevering betekent dat er, zonder additionele maatregelen, geen zekerheid is dat alle messages uit de operationele applicaties ontvangen zijn. Om deze reden moet er na het afsluiten van een periode (een uur, een dag) een synchronisatie controletotaal verstuurd worden, zodat de ontvangstomgeving in het financiële domein kan controleren dat alle berichten zijn ontvangen. De bovenstaande controle is aanvullend op de controletotalen, die de message infrastructuur zelf uitvoert op de verzending en ontvangst van messages. De message infrastructuur bewaakt namelijk dat een verstuurde message ook daadwerkelijk wordt afgeleverd c.q. de verzender een bevestiging ontvangt dat dit wel of niet gelukt is (ACK/NACK). Dit mechanisme is vergelijkbaar met de standaard netwerk package controles, maar dan ingericht voor logische messages. Bij de verwerking voor de financiële verslaglegging moet de verwerking stoppen als de IT technische controletotalen signaleren dat er verschillen zijn opgetreden. Op dat moment treedt de incident procedure in werking en moet beoordeeld worden welke actie(s) noodzakelijk is om de IT technische verwerking toch volledig te krijgen. De IT technische reconciliatie tussen de operationele applicaties, ontvangstomgeving, rules engine, datawarehouse, grootboek en rapportages zijn van dezelfde aard. IT technisch moet elke verwerking controleren dat alle bestanden, messages of database tabellen technisch correct zijn verwerkt. Het is geen strikte noodzaak, dat de IT controletotalen in dezelfde omgeving worden geplaatst als de operationele- en financiële controletotalen. 7.4
Reconciliatie basisadministratie
De operationele controletotalen voor de basisadministratie, die in deze paragraaf beschreven worden, zijn gericht op financiële verslaglegging. Het operationele domein moet bewaken, dat alle mutaties die leiden tot een wijziging in de verslaglegging ook daadwerkelijk worden doorgegeven. Door de inrichting van controletotalen voor het operationele domein en deze op te nemen in de financiële reconciliatieomgeving krijgt de financiële afdeling de mogelijkheid om te controleren of de aansluiting van beginstand + toenames - afnames = eindstand naar de verschillende dimensies. De financiële afdeling moet de reconciliatie eisen voor het operationele domein expliciet maken. De definitie van het begrip mutatieperiode is essentieel voor het juist vaststellen van controletotalen. In het verleden was boekdatum de richtlijn voor deze periode, echter als gevolg van ‘intraday settlements’ bij betalingen worden de eisen nog hoger en moeten operationeel gezien ook binnen de dag de controletotalen worden opgebouwd en gecontroleerd. Voor de financiële verslaglegging moet een duidelijke keuze worden gemaakt of deze verhoogde eis ook noodzakelijk is. De definitie van het begrip datum is ook essentieel voor het inrichten van controletotalen en een bron van verstoringen in het bepalen van de juiste controletotalen. Het bankwezen hanteert verschillende definities: •
Mutatiedatum – De datum waarop een mutatie wordt vastgelegd in de basisadministratie, onafhankelijk of dit een financiële mutatie is en of deze wel/niet is doorgegeven aan de financiële administratie.
•
Boekdatum – De datum waarop een mutatie als financiële gebeurtenis en/of als positie moet worden geregistreerd en dus wordt doorgegeven aan de financiële administratie. De datum stuurt de controletotalen, want deze stuurt het logistieke proces om gegevens aan de financiële administratie door te geven.
•
Valutadatum – De datum waarop een financiële gebeurtenis met klant wordt verrekend. Deze datum is essentieel voor het bepalen van de financiële posities. 36
De mutatiedatum is niet relevant voor de financiële verslaglegging. De controletotalen voor de financiële verslaglegging kunnen ingedeeld worden in: •
Controle op aantallen mutaties naar mutatietype (event total) in een mutatieperiode uitgevoerd conform boekdatum, die doorgegeven zijn aan de financiële administratie
•
Controle op totalen van mutatiebedragen per mutatieperiode. De periode kan bepaald worden met de boekdatum. Deze totalen kunnen worden ingericht naar verschillende criteria, zoals gesplitst in product(categorieën), statusovergangen, bij- en afboeking.
•
Controle op aantallen contracten (posities) op een periodeovergang volgens boekdatum en volgens valutadatum uitgesplitst naar gewenste product(categorieën) en status.
•
Controle op gesommeerde contractwaarden al dan niet gesplitst in product(categorieën) en status (bijv. aanvraag, offerte, geaccepteerd, gepasseerd, gesloten) op een periodeovergang, waarbij de contractwaarde wordt uitgedrukt als de gesommeerde waarde op boekdatum en gesommeerde waarde volgens de valutadatum.
De complexe bovenstaande definitie biedt de mogelijkheid om de volgende verbandscontroles vast te stellen voor het operationele domein: •
Begin boekwaarde op boekdatum + bijboekingen op boekingdatum – afboekingen op boekdatum = eind boekwaarde op boekdatum
•
Beginpositie op valutadatum – {vooruitboekingen (bijboekingen – afboekingen)} + {naboekingen (bijboekingen – afboekingen)} = eindpositie op valutadatum
De financiële administratie moet vervolgens bepalen op basis van materialiteit welke uitsplitsing naar debet en credit, product(categorieën) en status vereist is. Uitgangspunt is dat bij afwijkingen geconstateerd kan worden in welke ‘mutatiestroom’ de afwijking is ontstaan, zodat de afwijking onderzocht kan worden en hersteld kan worden. De IT auditor voor het reconciliatieproces moet samen met de financieel auditor valideren of de controletotalen qua opzet, bestaan en werking correct zijn ingericht en correct worden bepaald. Hierbij moeten de bovenstaande verbandscontroles worden aangetoond. Van groot belang is, dat de controletotalen opnieuw bepaald kunnen worden, zodat na een herstelactie alsnog de correct totalen in de reconciliatie zichtbaar worden. Hierbij is onderbouwing van de herstelde controletotalen van belang. Voor het opnieuw bepalen van de controletotalen wordt de term kalibreren of herijken gehanteerd. In de audittrail van de reconciliatie moet de motivatie van de herijking worden vastgelegd. 7.5
Reconciliatie ontvangstomgeving
De controletotalen voor de ontvangstomgeving worden onafhankelijk afgeleid van de IT technische opslag van de mutaties in de ontvangstomgeving. De controletotalen worden met identieke criteria als het totaal voor de mutatieperiode in de operationele applicaties bepaald. Opmerking: in de ontvangstomgeving worden nadrukkelijk alleen mutatietotalen bepaald, en geen positie totalen, want de ontvangstomgeving beschikt niet per definitie over alle gegevens. De mutatietotalen worden vergeleken. Bij afwijkingen wordt de incident procedure gestart en wordt er eventueel hersteld, waarna de controletotalen opnieuw worden bepaald. De controle in de ontvangstomgeving zorgt ervoor, dat ontbrekende of dubbele verwerking van messages in een vroeg stadium wordt gesignaleerd en hier op kan worden gereageerd. 7.5.1 Reconciliatie tussen ontvangstomgeving en ‘rules engine/ETL’ De ‘rules engine/ETL’ interpreteert de gegevens uit de ontvangstomgeving en vertaalt deze naar journaalposten. Het effect van de rules engine is dat een event gesplitst of samengevoegd wordt. Van elke toegepaste ‘rule’ moet exact bekend zijn welk aantal journaalposten gecreëerd wordt op basis van de (verzameling) events, zodat het totaal aantal gecreëerde journaalposten vergeleken kan worden met het aantal keer dat een rule is toegepast. Hierbij is het van belang, dat er 3 typen rules bestaan: •
1 mutatie in ontvangstomgeving creëert 1 journaalpost Æ conversie
37
o •
•
Betaalbaarstelling van een hypotheek
1 mutatie in de ontvangstomgeving creëert x journaalposten Æ explosie o
Boeken naar verschillende grootboeken, doordat een dubbel grootboek gevoerd moet worden vanwege verschillende principes (voorbeeld volgens Islamitische regels is het ongewenst rente te boeken, en wordt via een andere berekening een vorm van betaling voor een dienst geboekt i.p.v. rente).
o
Boeken naar memo accounts om een andere uitsplitsing te maken t.b.v. verschillende rapportage uitgangspunten (US GAAP, IFRS)
o
Rentebetaling
Y mutaties creëren 1 journaalpost Æ aggregatie o
Alle rekeningcourant mutaties met dezelfde boek en valutadatum worden als één journaalpost geboekt.
De rules engine moet voor de reconciliatie elke uitvoering van een rule in een audittrail plaatsen met daarbij de zgn. rules factor. Deze factor geeft de conversie, explosie en aggregatie aantallen weer. Deze audittrail bevat ook het debet en creditbedrag dat door de rule wordt gecreëerd. Verder wordt hier een rules engine kenmerk toegekend, zodat altijd traceerbaar is welke omzetting heeft plaatsgevonden. Op basis van dit kenmerk kan in een later stadium een herstelactie worden uitgevoerd bij een eventuele fout in de gedefinieerde rule. De volgende verbandscontroles zijn op de rules engine van toepassing: •
Volledigheid mutatieverwerking = aantal mutaties in ontvangstomgeving = aantal verwerkte mutaties door rules engine
•
Mutatie controle
= som van de mutaties vermenigvuldigd met de rules factor
= aantal gegenereerde journaalposten •
Journaalpostcontrole = totaal van debet = totaal van credit
De financiële afdeling moet bepalen welke controletotalen gereconcilieerd moeten worden tussen de rule engine en het grootboek. Deze controletotalen moeten op basis van gegenereerde journaalposten worden bepaald. Het onderscheid in boekingsperiode, vooruitboeking en naboeking op basis van boekingsdatum en valudatum moet hier ook gemaakt worden. Additioneel moet onderscheid worden gemaakt in totalen naar verschillende boeken, balans en W&Vrekeningen, en master en memo accounts. De verschilboekingen tussen boeken moeten ook als totalen worden vastgelegd, zodat deze gebruikt kunnen worden om de reconciliatie tussen verschillende grootboeken te ondersteunen. 7.6
Reconciliatie grootboek
De door de rules engine gegenereerde journaalposten met een rules engine kenmerk worden verwerkt in het grootboek binnen een boekingsperiode. Deze verwerking moet weer voldoen aan de IT richtlijnen voor controletotalen. Om vast te stellen, dat alle journaalposten zijn verwerkt in het grootboek, worden de controletotalen, die tijdens het opbouwen van de journaalposten door de rules engine zijn gemaakt, vergeleken met de totalen uit het grootboek. De criteria voor het bepalen van deze totalen sluiten aan bij de criteria voor de rules engine totalen. Daarnaast worden de totalen van de verschillende boeken met elkaar vergeleken op basis van het grootboek en deze verschillen worden vergeleken met de controletotalen bepaald door de rules engine. Het rules engine kenmerk in de journaalposten is belangrijk, zodat de grootboek mutaties vanuit de rules engine herkenbaar blijven voor de reconciliatie. Binnen het grootboek kunnen mutaties ook ontstaan door handmatige invoer of ontstaan door boekingsregels vastgelegd in het grootboek zelf (afschrijvingen, voorzieningen, etc.) of worden gevoed vanuit andere bronnen dan 38
de rules engine. De reconciliatie met andere bronnen vindt op identieke wijze plaats en moeten dan ook een eigen kenmerk hebben. De selectiecriteria voor de controletotalen moeten rekening houden met de bron van de journaalposten. Tenslotte leidt het sluitingsproces van de boeken tot een ‘foto’ van het grootboek en de gegevens op dat moment leiden tot de balans en de verlies & winstrekening naar de verschillende inzichten. Het moment van het sluiten van de boeken wordt gedreven door het feit, dat er na het sluiten van de boeken geen materiële mutaties meer plaatsvinden, die qua valutadatum betrekking hebben op de vorige periode. Voor deze zgn. transposten moeten vanuit de financiële verslaglegging een goede en gefundeerde inschatting gemaakt worden, zodat het grootboek een zo getrouw mogelijk beeld van de werkelijkheid geeft. De doelstelling van de reconciliatie is dat uiteindelijk het grootboek de juiste gegevens bevat en als WAARHEID kan worden beschouwd. De reconciliaties voor de basisadministratie, de ontvangstomgeving, rules engine en grootboek hebben hiertoe geleid. Vanaf dit punt in het boekingsproces en sluitingsproces kan het grootboek als de WAARHEID worden beschouwd en gebruikt worden als uitgangspunt voor de reconciliatie met het datawarehouse en de rapportages. 7.7
Reconciliatie datawarehouse
De inrichting van een financieel datawarehouse naast het grootboek is voor de banken in Nederland gebaseerd op een aantal redenen: 1. Een grootboek kan vrijwel onmogelijk alle details bevatten om aan alle rapportage eisen te voldoen of dit vereist dermate veel additionele boekingen dat dit niet efficiënt is. Daarnaast worden de rapportage eisen regelmatig aangepast en dit leidt tot ongewenste aanpassingen in het grootboek. 2. Een grootboek bevat per definitie alleen gegevens over het verleden en bevat geen gegevens over de toekomst, zodat de MA cyclus plannen en budgetteren onvoldoende met een grootboek wordt ondersteund. 3. Een grootboek omvat onvoldoende informatie om financiële analyses uit te voeren voor het bepalen van klantwinstgevendheid, specifieke processen, KPI-berekeningen en diverse model analyses (bijvoorbeeld activity based costing en real options). De organisatorische eis is echter wel dat deze berekeningen aansluiten bij de FA rapportage. 4. Een grootboek bevat in het algemeen beperkte informatie over risico’s (kredietrisico, markrisico, valuta & renterisico en verzekeringsrisico), terwijl vanuit DNB deze wel vereist zijn. Bij deze risicorapportages is echter de aansluiting bij het grootboek wel een vereiste. Dit referaat gaat verder niet in op de discussie of een datawarehouse daarvoor een geëigende weg is. DNB, belastingdienst en PCAOB accepteren een datawarehouse als bron voor financiële rapportage mits aangetoond wordt dat de aansluiting met het grootboek geen materiële verschillen vertoond. Het reconciliatieproces moet deze aansluiting bewaken en bij voorkeur ook de mogelijkheid bieden om afwijkingen inzichtelijk te maken. Voor elk financieel datawarehouse moet het uitgangspunt zijn, dat het grootboek leidend is en het datawarehouse slechts een multi-dimensionele indeling van dezelfde gegevens bevat. De IT auditor moet bij de beoordeling van het reconciliatieproces nadrukkelijk onderzoeken of de gekozen IT verwerkingsarchitectuur voldoet aan deze eis.
39
Financieel domein schematisch weergegeven Een financieel datawarehouse kan wel additionele gegevens bevatten, die gerelateerd zijn aan de financiële gegevens om aan andere rapportage verplichtingen (markt-, krediet en verzekeringsrisico’s) of organisatorische rapportages (MA) te voldoen. De gegevens al dan niet financieel gerelateerd worden in het financieel datawarehouse geladen, zodat de data marts gegenereerd kunnen worden om te voldoen aan de verschillende rapportage eisen. De rules engine kan ook een deel van het datawarehouse vullen, zodat de consistentie tussen het datawarehouse en het grootboek versterkt wordt. Hierbij moet IT technisch beoordeeld worden of dit gewenst is qua performance voor het grootboek, want het parallel laden van het datawarehouse zou (ongewenst) vertragend kunnen werken op het vullen van het grootboek. Het is een feit, doordat het datawarehouse meer detailgegevens bevat dan het grootboek, dat het vullen van het datawarehouse een langere doorlooptijd kent. Uiteraard is dit door IT maatregelen (extra hardware en performance tuning) te verbeteren, maar onder gelijke condities is dit per definitie trager. De eerste reconciliatiecontrole voor het datawarehouse is t.o.v. het grootboek. Hierbij worden de controletotalen uit het grootboek vergeleken met de controletotalen gebaseerd op het datawarehouse. Om de controle totalen goed te bepalen moet de mutatieperiode van het grootboek en het datawarehouse identiek zijn. De gecombineerde verwerking van rules engine naar grootboek en datawarehouse biedt hiervoor extra waarborgen. De tweede controle voor het datawarehouse is de reconciliatie t.o.v. de basisadministraties. Het datawarehouse kan fout zijn t.o.v. de basisadministratie, doordat de aanlevering vanuit de basisadministratie niet volledig is c.q. de ETL programmatuur om het datawarehouse op te bouwen de gegevens niet correct verwerkt. Het datawarehouse moet op identieke wijze als de basisadministratie de totalen bepalen. Het datawarehouse moet ook hier over dezelfde mutatieperiode de totalen bepalen. Bij verschillen in de driehoekrelatie tussen basisadministraties, grootboek en datawarehouse vindt onderzoek plaats. Hier speelt het uitgangspunt, dat het grootboek leidend is een belangrijke rol. Als er verschillen zichtbaar worden en het probleem blijkt in het grootboek te zitten, dan zal eerst het grootboek hersteld moeten worden, maar dit mag NIET gebeuren vanuit het datawarehouse. Vanuit IT audit perspectief mag er dus ook geen programmatuur zijn om vanuit het datawarehouse het grootboek te vullen of te verbeteren. De basisadministratie moeten zorgen, dat de juiste correcties worden aangebracht. Als het probleem in het datawarehouse zit, dan moet het datawarehouse worden hersteld. Door het karakter van het datawarehouse en het feit dat het grootboek leidend is, is hier geen ernstig
40
bezwaar tegen, tenzij op deze (foute) basis al FA rapportages zijn uitgevoerd. Na de herstelactie wordt de reconciliatie tussen grootboek en datawarehouse opnieuw uitgevoerd, en kan de rapportage worden uitgevoerd. De historische gegevens van het datawarehouse kunnen worden verrijkt met additionele gegevens of meer detailgegevens. Deze situatie doet zich voor als er nieuwe rapportage eisen worden gesteld, waarvoor ook de historische financiële gegevens noodzakelijk zijn, maar deze niet in het grootboek worden vastgelegd. Deze eis voor additionele gegevens in het datawarehouse doet zich met name voor bij ‘voorspellende’ rapportages over financiële gegevens gebaseerd op risico modellen. Voor de IT auditor van het reconciliatieproces is het van belang om vast te stellen, dat de historische totalen (als basis gehanteerd voor de rapportage) ook na de aanvullingen nog in tact zijn. De reconciliatie applicatie moet dus ook intern de totalen kunnen reconcilieren door opnieuw een foto te maken van de totalen. Met deze functionaliteit wordt de reconciliatie applicatie ook een fundament voor de bewaking van conversies in de diverse applicaties. 7.8
Reconciliatie financiële rapportage
Het schema in de vorige paragraaf geeft weer dat er vanuit het datawarehouse rapportages worden gecreëerd. Deze rapportages worden veelal elektronisch vastgelegd en elektronisch aangeleverd aan externe partijen, zoals belastingdienst, AFM, DNB. Deze rapportage stroom wordt veelal vastgelegd in specifiek bestandsformaten, die gedicteerd worden door de ontvanger. De programmatuur die het bestand aanmaakt, die soms m.b.v. kantoorautomatiseringshulpmiddelen (bijv. MsExcel of MsAccess) wordt gemaakt, vormt vanuit IT audit perspectief een risico. Deze laatste stap zou alle getroffen reconciliatie maatregelen in één keer teniet kunnen doen. Om deze reden moeten de opgeleverde rapportages ook in de reconciliatie worden opgenomen. De totalen uit de rapportages moeten worden gereconcilieerd met het grootboek en datawarehouse totalen. Een aandachtspunt hierbij is dat de controletotalen voor de rapportage periode, mogelijk opgelegd door de externe partij, kunnen afwijken van de intern gehanteerde rapportage periodes. In de reconciliatie moeten dan de ook totalen worden opgenomen, die overeenkomen met de extern vereiste periode. Een voorbeeld van een dergelijke verschillende opvatting is bijvoorbeeld i.p.v. maandelijks, dat er vierwekelijks gerapporteerd moet worden. Het opnemen van de rapportagetotalen, biedt ook de gelegenheid om een totaalbeeld te hebben van de opgeleverde rapportages. 7.9
Monitoring en audit trail van de reconciliatie
In de voorgaande paragrafen is meerdere keren verwezen naar de audit trail. De reconciliatie is de controle op een gecompliceerd logistiek gegevensproces, waarbij op diverse plaatsen in dit proces kwaliteitscontroles worden uitgevoerd door de financiële afdeling. Het monitoren van het logistieke proces gebeurt door alle verschillende controletotalen uit de verschillende applicaties door te geven aan de reconciliatieapplicatie. Deze controletotalen worden aangeleverd op het moment dat de IT verwerking (in basisadministraties, ontvangstomgeving, etc.) een specifiek punt bereiken. De aanlevering van de controletotalen leidt tot het activeren van een reconciliatie activiteit. Dit gebeurt bijvoorbeeld als de basisadministratie klaar is en de ontvangstomgeving ook klaar is voor een specifiek product, zodat de reconciliatie gedaan kan worden. Het monitoren van de financiële reconciliatie is vergelijkbaar met het monitoren van de IT verwerking, maar dan vanuit een financieel perspectief. Hierbij wordt opgemerkt, dat het mogelijk moet zijn om vanuit de IT verwerking te controleren of een specifieke reconciliatie wel of geen verschillen heeft opgeleverd om vervolgens te bepalen of de verwerking door kan gaan. Dit heeft als voordeel dat de financiële afdeling ook specifieke goedkeuringsregels kan aangeven om de IT verwerking door te laten gaan. Deze besturing op de IT zorgt voor een verhoogde beheersing van het financiële rapportageproces. De reconciliatie applicatie moet in het reconciliatieproces ook de mogelijkheid bieden om bij eventuele, niet materiële, verschillen de voortgang door te drukken. Eerder is al beschreven, dat het mogelijk moet zijn om controletotalen meerdere keren te kunnen aanleveren. Dit is
41
noodzakelijk als er IT technische herstelwerkzaamheden plaatsvinden of er aangepaste boekingen hebben plaatsgevonden. 7.10 Positionering van reconciliatieapplicatie De financiële afdeling is eigenaar van de reconciliatieapplicatie. Qua applicatiearchitectuur kan de reconciliatieapplicatie verschillend geplaatst worden. De volgende posities kunnen worden overwogen: •
Binnen basisadministratie Æ minder controle vanuit de controller
•
Binnen grootboek Æ controller beheerst deze omgeving, maar het grootboek kent vaak geen functionaliteit om controletotalen en een reconciliatie workflow vast te leggen. Daarnaast is de veranderfrequentie van het grootboek is mogelijk onvoldoende om te voldoen aan de verschillende eisen.
•
Binnen DWH Æ controller beheerst omgeving, maar workflow functionaliteit is DWH vreemd en veranderfrequentie van DWH is mogelijk onvoldoende hoog
•
Separate applicatie Æ controller beheerst omgeving, workflow kan worden ondersteund, en veranderfrequentie is beïnvloedbaar.
Voor het reconciliatie proces moet vanuit IT audit perspectief beoordeeld worden of de gemaakte keuze voor de applicatie op juiste gronden en weloverwogen is gemaakt. De feitelijke positie is hierbij afhankelijk van de gehele IT inrichting.
42
8 8.1
Conclusies Inleiding
In de voorgaande hoofdstukken hebben de diverse aspecten van SOA en het reconciliatieproces de revue gepasseerd. Dit laatste hoofdstuk bevat de conclusies en aanbevelingen voor een financiële instelling die een Service Oriented Architecture heeft of introduceert en met een gedegen reconciliatieproces de volledigheid van de financiële verslaglegging wil beheersen. 8.2
SOA veroorzaakt risico’s voor de financiële verslaglegging
SOA introduceert extra risico’s voor de vertrouwelijkheid, integriteit en beschikbaarheid, want de introductie van de services leidt per definitie tot de inrichting van een message infrastructure. Deze message infrastructure kan leiden tot het bewust en onbewust ongeautoriseerd aanpassen, verwijderen en toevoegen van messages, waardoor de integriteit van de financiële verslaglegging verslechtert. De messages worden verstuurd over het netwerk en hierdoor kunnen, bij onvoldoende beveiligingsmaatregelen, de messages worden gelezen door ongeautoriseerde personen. Hierdoor wordt de vertrouwelijkheid geweld aangedaan. De message infrastructure wordt beschouwd als een IT technisch complexe materie, waarbij verschillende platformen gekoppeld worden. Eventuele technische verstoringen kunnen de beschikbaarheid van de message infrastructure messages verstoren, waardoor de beschikbaarheid van de gegevens voor het financiële domein wordt verminderd. 8.3
SOA vereist extra aandacht voor general IT controls
SOA dwingt tot authenticatie en identificatie eisen voor vertrouwelijkheid, integriteit, beschikbaarheid en controleerbaarheid op service niveau en een heroverweging van het RBACmodel vereisen. Essentieel is dat de authenticatie, identificatie en autorisatie plaatsvindt op entity service niveau. 8.4
Reconciliatie is vereist van de bron tot en met de rapportage
De gegevensverwerking vanaf klanten, bedrijven en tegenpartijen richting de banken tot de uiteindelijke financiële verslaglegging richting toezichthouders en andere externe partijen is in grote mate geautomatiseerd door een aaneenschakeling van verschillende applicaties. Vanuit de wetgeving (SOx) en toezichthouders (DNB, AFM) wordt geëist dat de banken aantonen, dat de gegevensverwerking correct is verlopen en de financiële verslaglegging volledig en juist is, en daarmee een ‘getrouw beeld van de werkelijkheid geeft’. Hiervoor moeten de banken vaststellen, dat de gegevensverwerking van de bron tot en met de rapportage correct is verlopen. Het reconciliatieproces ondersteunt deze controle door via verbandscontroles verschillen aan het licht te brengen. 8.5
Reconciliatie ondersteunt de functiescheiding binnen de financiële verslaglegging
Reconciliatie biedt mogelijkheid om aanvullend op de functiescheiding en logische toegangsbeveiliging de interne controle te versterken door actief de omspannende controle totalen te bewaken. Reconciliatie en SOA bieden nieuwe mogelijkheden voor striktere interne controle door geautomatiseerde functiescheiding tussen de vastlegging van mutaties, registratieve mutaties en resultatieve mutaties voor financiële verslaglegging. De functiescheiding tussen registratief en resultatief wordt sterker ondersteund, doordat de resultatieve cijfers vergeleken worden met de registratieve cijfers. 8.6
Reconciliatie ondersteunt SOx regelgeving
De SOx regelgeving heeft als doel om aan te tonen, dat een onderneming de financiële verantwoording volledig beheerst. Hierbij heeft de wetgeving ook als doel om overtreders juridisch te kunnen vervolgen. Het reconciliatieproces toont aan dat gegevensverwerking correct werkt en de omspannende controletotalen ook correct zijn. Dit versterkt de zekerheid over de opgeleverde financiële verslaglegging.
43
8.7
Reconciliatie informatie als koppeling naar ‘audit around the computer’
De accountant steunt op de inhoud van de financiële informatiesystemen voor de controle van de jaarrekening. De reconciliatie informatie biedt de accountant inzicht in de wijze, waarop de informatie in het financiële informatiesysteem tot stand is gekomen. Daarnaast krijgt de accountant inzicht, hoe geautomatiseerde gegevensverwerking gedurende de controleperiode is verlopen en welke verschillen hierdoor zijn opgetreden. Als het inzicht dat het reconciliatie informatiesysteem biedt op een juiste wijze aan de accountant wordt aangeboden, zal de controle van de financiële informatiesystemen eenvoudiger verlopen en kan de accountant steunen op de door de IT auditor gecontroleerde reconciliatie van de geautomatiseerde gegevensverwerking. 8.8
Tot slot
De inspiratie voor dit referaat is ontstaan uit nieuwsgierigheid naar de financiële informatiesystemen van ING en de inrichting van een nieuw grootboek voor geheel ING, en voor ING Retail NL in het bijzonder. Bij de implementatie van dit grootboek speelt het reconciliatie vraagstuk een belangrijke rol. Met dit referaat hoop ik een kleine bijdrage te leveren aan de juiste beeldvorming over de reconciliatie problematiek en mogelijke oplossing voor ING. ING heeft mij de gelegenheid geboden om deze zoektocht zelfstandig uit te voeren en dit zowel vanuit het controller perspectief, vanuit het IT perspectief als vanuit het IT audit perspectief te mogen onderzoeken. In het bijzonder wil ik de heer Niels van Weeren (ING) bedanken voor de ruimte en steun, die hij mij heeft gegeven om de opleiding postdoctoraal IT audit te volgen en mijn onderzoek uit te voeren. Daarnaast wil ik de heer Rob Christiaanse (begeleider VU Amsterdam) bedanken voor zijn inspirerende begeleiding, zijn enthousiasme voor het onderwerp en zijn opbouwende opmerkingen, die hebben geleid tot een dieper inzicht in de materie van reconciliatie en IT audit.
Tom Wever te Assendelft, 1 april 2007
44
I
Bijlage Literatuurlijst
Diverse documentatie van ING N.V. t.a.v. IFSA; SOA implementatie voor ING N.V.; 1998-heden DNB; Financiële Instellingen Risicoanalyse Methode (FIRM); http://www.dnb.nl/dnb/home/toezicht/handboek_firm/nl/12-114976-64.html ; geraadpleegd op 22 december 2006 Erl, Thomas; Service-Oriented Architecture - Concepts, Technology and Design; Pearson Education Inc. ISBN 0-12-185858-0; 2005 Haelst, Werner van & Schut, Donald; ERP-systemen in de nutssector: een energieke combinatie!; EDP-auditor nummer 2 – 2004 ISO-IEC; Information technology – Security techniques – Code of practice for information security management; ISO-IEC 17799:2005(E); 2005 Koning, Drs. W.F. de – Handboek EDP-auditing Het Clark-Wilson-model – afl. 13 (april 1997) Praat, Jan van & Suerink, Hans; Inleiding EDP-auditing; ten Hagen & Stam Uitgevers; ISBN 90 440 07599; 2004 Taylor, Hugh; Managing SOX in the age of SOA ; SOA WebService Journal July 2006/volume 6 issue 7 http://soagovernancearchitect.com ; geraadpleegd op 5 november 2006 Thiadens, Theo; Beheer van ICT-voorzieningen – infrastructuren, applicaties en organisatie; Academic Service; ISBN 90 395 1390 2; 1999 Verschillende auteurs; IT Control Objectives for Sarbanes-Oxley; IT Governance institute; ISBN 1893209-67-9; 2003
45
