Robert Johan: De (on)zin van database beveiliging bij beoordeling betrouwbaarheid lijstwerk

De AFM voert kwaliteitsonderzoeken uit op wettelijke controles bij accountantskantoren. Het kwaliteitsonderzoek richt zich ook op de mate waarin de accountant aandacht heeft besteed aan de General IT Controls. General IT controls zijn interne beheersingsmaatregelen met betrekking tot de geautomatiseerde gegevensverwerking en dienen de betrouwbare werking van deze geautomatiseerde gegevensverwerking te waarborgen. Een herkenbare opmerking uit de kwaliteitsonderzoeken van de AFM betreft dat de externe accountant geen of onvoldoende werkzaamheden heeft uitgevoerd om de general IT controls en application controls te beoordelen terwijl hij wel volledig steunt op de informatie en het lijstwerk. Lijstwerk betreft hierbij de voor de accountantscontrole relevante output uit applicaties. Denk hierbij aan een ouderdomsanalyse debiteuren ten behoeve van het bepalen van de voorziening debiteuren of een overzicht met prijzen per artikel ter controle van de juistheid van de prijzen.

Een van de general IT controls betreft de database beveiliging van applicaties De database beveiliging van een applicatie kan effect hebben voor de betrouwbaarheid van het lijstwerk. Mijn inziens wordt database beveiliging op een onjuiste wijze betrokken bij de accountantscontrole waardoor verkeerde conclusies omtrent de betrouwbaarheid van lijstwerk worden getrokken. 

Om de (on)zin van database beveiliging bij beoordeling van de betrouwbaarheid van het lijstwerk bij een accountantscontrole te kunnen bepalen zal een accountant moeten starten met een adequate inventarisatie van de IT en de database beveiliging. Inventarisatie is noodzakelijk om minimaal vast te stellen welke risico’s voor de betrouwbaarheid van het lijstwerk aanwezig zijn. Vervolgens dient men rekening te houden met de waarschijnlijkheid van manipulatie van de database: bijvoorbeeld in hoeverre kan iemand ongeautoriseerde prijzen in verkoopfacturen wijzigen? Feit is dat bij wijzigingen rechtstreeks in de database de interne beheersingsmaatregelen in de applicatie (application controls) mogelijkerwijs worden omzeild. Denk bij application controls aan geïmplementeerde functiescheidingen aan de hand van autorisatietabellen in de applicatie.

Uiteraard zijn er risico’s te bedenken maar deze dienen wel in het juiste kader te worden geplaatst. Ondeskundige manipulatie van een database heeft gevolgen voor de database-integriteit: mismatch tussen diverse verbanden. Deskundige manipulatie kan behoorlijk wat deskundige arbeid vergen, het is daarom niet altijd waarschijnlijk.

Op basis van de inventarisatie en de risico-analyse kan de accountant uiteindelijk komen tot het uitvoeren van de juiste werkzaamheden om de database beveiliging te beoordelen waardoor hij een juiste conclusie kan trekken of hij kan steunen op het lijstwerk.

Introductie database

De huidige applicaties maken tegenwoordig meestal gebruik van een database waarin alle data centraal wordt opgeslagen. Als een gebruiker van een applicatie zoals SAP B1 de prijs van een product wijzigt, dan zal deze wijziging worden doorgevoerd in de onderliggende database in de tabel ’prijzen’.

 

 

 

Niet iedere gebruiker zal prijswijzigingen mogen doorvoeren. In de applicatie worden gebruikers aangemaakt. Deze gebruikers krijgen, eventueel via rollen/groepen, autorisaties. Zo wordt bepaald welke gebruikers prijzen mogen wijzigen.

In sommige gevallen beschikt een applicatie over een adequate audit trail waardoor achteraf inzichtelijk is welke wijzigingen in de autorisaties hebben plaatsgevonden. Op die audit trail moet dan gedocumenteerde interne beheersing zijn toegepast om vast te stellen dat autorisaties conform de vereisten werken.

Na te zijn opgeslagen in de tabel ‘prijzen’ in de database worden er transacties uitgevoerd door medewerkers die daar dan weer de autorisatie voor hebben. Die transacties worden weggeschreven in de database in de tabel ‘factuurdetails’.

Toegang tot de tabellen ‘factuurdetails’ en ‘prijzen’ in de MS SQL database worden op een ander niveau dan de applicatie geregeld, namelijk op de database server. Een gebruiker kan toegang krijgen via specifieke tools.

 

Eens per week, maand of verslagperiode is het vervolgens voor een gebruiker belangrijk om te weten wat de inhoud is van een dergelijke database. Dan wordt een rapport gedraaid, in reviewverslagen ook wel ‘lijstwerk’ genoemd. Dat ‘lijstwerk’ is meestal een algoritme, een commando dat informatie uit de database pakt en die op een voorgeprogrammeerde plaats op een overzicht zet. Een voorbeeld is een overzicht met prijzen per artikel ter controle van de juistheid van de prijzen.

Mogelijke consequenties voor de controle

In reviewverslagen van accountantsdossier door bijvoorbeeld toezichthouders of compliance officers zie ik terugkomen dat er opmerkingen worden gemaakt over de ‘betrouwbaarheid van het lijstwerk’. Deze formulering is van een geaggregeerd niveau en valt uiteen in een aantal deelrisico’s:

1. Iemand met een onjuiste autorisatie voert een prijswijziging door of voert een transactie uit. Dit betekent dat er een transactie tot stand komt buiten de gewenste bandbreedtes. Die transactie wordt vervolgens weggeschreven naar de database in de tabel ‘factuurdetails’.
2. Na opname in de tabel ‘factuurdetails’ benadert iemand direct de database en muteert die gegevens. Daarbij dient men rekening te houden met het steeds verdergaand “openzetten” van databases ten behoeve van diverse doeleinden zoals management information tools waarbij medewerkers op een andere wijze dan via de applicatie zelf toegang hebben tot de database.
3. Bij het ophalen uit de database is het algoritme waarmee de gegevens worden gepresenteerd onjuist.

Ad 1) Onjuiste autorisaties

Ten aanzien van het risico op onjuiste autorisaties geldt, dat onjuiste functiescheiding vaak geen relatie heeft met de traceerbaarheid van een transactie. De functiescheiding in de applicatie regelt alleen de transactie zelf, niet de registratie ervan. Ontbreken van adequate functiescheiding in de applicatie gaat dan niet noodzakelijkerwijs ten koste van de controleerbaarheid achteraf.

Ad 2) Mutaties in database
Ten aanzien van het risico op ongeautoriseerde mutaties in de database geldt dat dit vaak wel kan, maar technisch bijzonder complex is. Manipulatie van een database vergt:

• kennis van het datamodel;
• kennis van commando’s om mutaties te kunnen uitvoeren;
• de juiste toegang tot de databases.

Bovendien is een database dusdanig complex dat het muteren van een bestaand record vaak de relatie verstoort met een controlegetal in een andere tabel (van de soms duizenden tabellen).  Zo zal een geboekte factuur waarvan de prijs is gemanipuleerd een mismatch vertonen met:

• openstaand bedrag in de tabel debiteurenposten;
• verkoopbedrag in de tabel goederentransactie;
• BTW-bedrag in tabel BTW-posten

Daarnaast bestaat de mogelijkheid om gegevens te verwijderen uit een database, bijvoorbeeld een log regel (registratie van een wijziging in autorisaties) of een transactie regel, bijvoorbeeld factuurdetail. Voor wat betreft het verwijderen van een transactie: hierbij moet specifieke kennis aanwezig zijn om te weten in welke andere tabellen dan ook regels verwijderd moeten worden (zie voorbeeld eerder). 

Manipulatie van transacties in een database met onvoldoende kennis van het datamodel zal resulteren in gevolgen voor de integriteit van de database zoals het niet sluiten van bijvoorbeeld een openstaande debiteurenpost met het saldo op grootboekkaart Debiteuren. In het ergste geval kan ondeskundige manipulatie resulteren in het niet meer in balans zijn van het grootboek. Daarnaast hanteert een beetje volwassen database een oplopend nummering (recordID). Let op, een recordID is iets anders dan een factuurnummer! Het verwijderen van een regel zal opvallen aangezien er een “gap” ontstaat in de oplopende nummeringen. Een beetje slimme beheerder zal dit weten, maar zal zich ook realiseren dat het omnummeren (handmatig) een behoorlijke klus kan zijn.

Ad 3) Manipulatie query lijstwerk

Ten aanzien van het risico op manipulatie van de query van lijstwerk geldt dat het bij standaard lijstwerken in generieke pakketten vrijwel alleen mis kan gaan bij instelling van het lijstwerk. Bij een instelling kun je denken aan een datumafbakening. De code waarmee de informatie wordt opgehaald is veelal simpel en de broncode om het lijstwerk te manipuleren is vaak niet bij de cliënt beschikbaar. Risicovol wordt deze laatste stap eigenlijk voornamelijk bij datawarehouses die naast de productieapplicaties draaien en waaruit vervolgens met eigen queries overzichten worden gemaakt of bij maatwerk omgevingen met “op maat gemaakte” lijswerken.

Werkprogramma accountant

Autorisaties. Vaak constateert een IT auditor dat de audit trail van wijzigingen niet betrouwbaar is, of de accountant constateert dat de wijzigingen in autorisaties niet door interne beheersing zijn gedekt. In dat geval moet de accountant dus nadenken over wat medewerkers met onjuiste autorisaties zouden gaan doen. Welke prikkel hebben ze en welke gelegenheid bieden de te ruimte autorisatie. Op basis van die afweging kan een accountant vervolgens gericht op zoek gaan naar transacties waar dat van toepassing lijkt te zijn in de database met gegevens.

Databasemutaties. Gebruikers van een systeem hebben vrijwel nooit direct toegang tot de database of zijn niet voldoende ge-equipeert om rechtstreeks in een database te muteren. Degene die dat vaak wel is, is vaak dezelfde persoon die de logging van directe mutaties in de database weet uit te zetten. Uiteraard dient het toekennen van toegang tot de database op een dusdanige wijze te gebeuren dat deze medewerkers alleen die autorisaties hebben die strikt noodzakelijk zijn. 

 

Mutaties van gegevens is echter niet gelijk aan verwijderen. De gegevens zijn nog wel opgenomen in de database. Manipulatie zou dan kunnen worden onderkend door gegevensgerichte werkzaamheden op de gegevens opgenomen in lijstwerken.

Het verwijderen van gegevens is niet altijd te onderkennen door gegevensgerichte werkzaamheden, niet ieder systeem houdt onder water Record ID’s bij.

Als een team van oordeel is dat verwijderen van records door de Databasebeheerder (in opdracht van de leiding van de huishouding) waarschijnlijk is, dan zijn gegevensgerichte werkzaamheden moeilijk. Het moet dan al mogelijk zijn om vanuit een andere gegevensbron (bijvoorbeeld de bank) een integrale afstemming te maken om te zoeken naar de verwijderde transacties. En anders is het niet te detecteren. Sommige versies van databases ondersteunen het loggen van database wijzigingen. Deze logging zal veelal niet ingericht zijn, naast het feit dat de inrichting van een logging de nodige expertise vereist.

De lijst zelf

Ten aanzien van de lijst zelf zouden de werkzaamheden van de accountant ten minste aandacht moeten besteden aan de opbouw en de oorsprong van een lijst. Is het een standaard lijstwerk uit een gekochte applicatie of is het een management information toepassing die put uit een datawarehouse dat naast de operationele database wordt gebruikt voor sneller rapporteren. In het geval dat het een standaard lijst betreft zouden werkzaamheden beperkt kunnen blijven tot het vaststellen dat de juiste peildatum of periode is gekozen in combinatie met het vaststellen dat sprake is van release beheer rondom wijzigingen. In het geval dat het een management information toepassing betreft dienen de werkzaamheden uitgebreid te worden met het maken van een totaalaansluiting tussen het datawarehouse en het operationele systeem in combinatie met het lezen van de code van de query.

Afsluitend

Met dit artikel wil ik een richting aangeven hoe de accountant databasebeveiliging dient te betrekken bij de accountantscontrole en hoe de accountant het effect van de bevindingen op de betrouwbaarheid van het lijstwerk kan bepalen. 

Robert Johan is register EDP-auditor en directeur bij Soll-IT. Hij ondersteunt accountantskantoren in het op de juiste wijze betrekken van de automatisering van organisaties in het controleren van de jaarrekening. Met dank aan Tom Koning die het onderwerp bij Robert Johan heeft aangedragen hetgeen uiteindelijk heeft geresulteerd in dit artikel.