Skip to main content

Themes

Audit & Assurance
Cyber Security & Privacy

Jaarrekeningcontrole en technische IT-beveiliging

IT-beveiliging is een belangrijk aspect dat de IT-auditor in het kader van de jaarrekeningcontrole dient te onderzoeken, in het bijzonder de technische IT-beveiliging. Deze technische IT-beveiliging is een randvoorwaarde om te kunnen steunen op IT-applicaties en daarmee verwerkte data. Ook is technische IT-beveiliging een randvoorwaarde voor IT General Controls, met name Access to Programs and Data en Program Changes. Dit vraagt om een onderzoek naar de technische IT-beveiliging.

Inleiding

De IT-auditor verzorgt in het kader van de jaarrekeningcontrole een onderzoek naar de betrouwbare geautomatiseerde gegevensverwerking. In het algemeen betreft dit een onderzoek naar de relevante IT-application controls en de IT General Controls (ITGC). Mede dankzij SOx is een duidelijker beeld ontstaan van de IT-aspecten die juist bij ITGC dienen te worden onderzocht. Het blijft echter de vraag in welke mate (scope en diepgang) de technische IT-beveiliging hierbij dient te worden geadresseerd. Ook kan de vraag worden gesteld of de algemene IT-auditor nog steeds de technische IT-beveiliging in een complexe IT-omgeving zelf kan beoordelen, of dat een gespecialiseerde technical IT-auditor hierbij een rol heeft.

Een beoordeling van de technische IT-beveiliging van de IT-omgeving betreffende een organisatie vereist net als bij andere beoordelingen een duidelijke opdrachtformulering, met name in termen van:

  • kwaliteitsaspecten;
  • diepgang;
  • mate van zekerheid;
  • objecten;
  • auditdoelstellingen;
  • normen;
  • werkwijze.

In dit artikel wordt de opdrachtformulering bij een onderzoek naar de technische IT-beveiliging nader toegelicht.

Aspecten van een audit naar technische IT-beveiliging

Kwaliteitsaspecten

Een accountant onderzoekt de jaarrekening om de getrouwe weergave van de balans- en resultaatposten evenals de daarbij geplaatste uitspraken (zogenaamde disclosures) te toetsen. Afhankelijk van de mate waarin voor een betrouwbare gegevensverwerking wordt gesteund op de IT-applicaties en IT-application controls, dient een onderzoek plaats te vinden naar de beheersing en de beveiliging van de IT-omgeving. Dit onderzoek betreft met name de integriteit en in enige mate de beschikbaarheid (ter overweging van de continuïteit van de bedrijfsvoering) van de geautomatiseerde gegevensverwerking en de data.

De vereisten voor de jaarrekeningcontrole dienen door de IT-auditor in samenwerking met de accountant te worden vertaald naar specifieke controledoelstellingen en normen, op basis waarvan een oordeel dient te worden gevormd over de geautomatiseerde gegevensverwerking in het kader van de jaarrekeningcontrole.

Diepgang en mate van zekerheid

Vroeger werd de IT-auditor gevraagd in het kader van de jaarrekeningcontrole in een beperkt aantal dagen zijn bevindingen inzake een IT-omgeving terug te koppelen naar de accountant. Later werd gevraagd om een meer concreet onderzoek uit te voeren naar de opzet en het bestaan van maatregelen inzake de geautomatiseerde gegevensverwerking. Mede dankzij de komst van SOx is de relatie tussen de jaarrekening, bedrijfsprocessen, application controls en ITGC verder geëxpliciteerd en wordt tegenwoordig aan de IT-auditor gevraagd de opzet en de werking van de geautomatiseerde gegevensverwerking te onderzoeken, teneinde op de werking van de IT-application controls te kunnen steunen. De diepgang van het onderzoek wordt hierbij direct afgeleid van de risico’s betreffende de jaarrekening.

Het onderzoek naar de werking van de ITGC vraagt van een IT-organisatie een bepaalde volwassenheid. Immers, een IT-auditor zal alleen een uitspraak over de werking van de ITGC kunnen doen, als de organisatie zelf enige mate van controle op naleving van gedefinieerde ITGC heeft bewerkstelligd. We spreken dan ook over aantoonbare beheersing (figuur 1).

C-2007-3-Kornelisse-1

Figuur 1. Volwassenheidsniveaus van IT-beveiliging.

Juist vanwege de voorwaarde van aantoonbare beheersing is het van belang dat een organisatie voor wat betreft technische IT-beveiliging standaarden heeft gedefinieerd en controle op naleving verricht. Deze standaarden kunnen zelf worden ontwikkeld, waarbij mede kan worden gesteund op beschikbare publieke middelen, bijvoorbeeld standaarden van het Platform Informatiebeveiliging (PI) en andere bronnen.

Aan de IT-auditor wordt gevraagd met een redelijke mate van zekerheid een oordeel te geven over de opzet en werking van een aantal ITGC. Voor een IT-auditor is een redelijke mate van zekerheid de hoogste mate van zekerheid die wordt afgegeven. Als het dan ook gaat om technische IT-beveiliging, impliceert dit een zorgvuldig onderzoek van de algemeen aanvaarde relevante systeemconfiguratieparameters. Immers, een door één parameter veroorzaakt lek is al voldoende om geen (redelijke mate van) zekerheid te hebben dat technische IT-beveiliging adequaat is geborgd.

Het is hierbij van belang te onderkennen dat het risico van het ontbreken van adequate technische IT-beveiliging hoger is geworden. Dit wordt op basis van de volgende formule toegelicht:

Risico = Dreiging × Verwachting × Impact

C-2007-3-Kornelisse-t1

Tabel 1. Risicoaspecten.

Waar voorheen de IT-auditor kon volstaan met de toetsing van enkele parameterinstellingen van een IT-component, is tegenwoordig de zorgvuldigheid van een meer uitvoerige toetsing van systeemconfiguratieparameters vereist, om het optreden van een dreiging te voorkomen waardoor een enkele onjuist ingestelde parameter zou resulteren in een onveilige IT-component, en daarmee (mogelijk) een onveilige IT-applicatie en resulterende onveilige data.

De omvang van IT-omgevingen van organisaties is ook dusdanig gegroeid, dat een integrale controle van alle relevante IT-componenten en van alle relevante systeemconfiguratieparameters een dusdanige inspanning vraagt, dat de verwachting van niet-ontdekte fouten toeneemt.

Veelal resulteert dit in de realisatie van een systeemgerichte aanpak, waarbij beveiligingsstandaarden worden toegepast en de mate van consistente implementatie en de controle op de naleving van deze standaarden wordt onderzocht.

Objecten

Binnen de IT-omgeving zijn diverse IT-componenten van belang (zie figuur 2).

C-2007-3-Kornelisse-2

Figuur 2. IT-componenten in de IT-omgeving.

Het is niet eenvoudig voor een IT-auditor de scoping uit te voeren van de relevante IT in het kader van de jaarrekeningcontrole ([Korn05]). Ten behoeve van het efficiënt en effectief uitvoeren van de te onderzoeken IT-componenten is scoping wel noodzakelijk. Daarom wordt de volgende aanpak aanbevolen:

  • Selecteer de applicatiespecifieke IT-componenten betreffende de door de accountant aangedragen relevante IT-applicaties. Dit resulteert in de selectie van applicatie- en databaseservers, bijvoorbeeld ERP-, grootboek- en consolidatiesystemen.
  • Selecteer de generieke IT-componenten, die onderdeel uitmaken van de IT-infrastructuur van de organisatie, waarmee organisatiebreed de beheersing, beveiliging en beschikbaarheid van IT wordt ondersteund. Denk hierbij aan het interne bedrijfsnetwerk, identity managementsystemen en beheer- en monitoringsystemen.

Deze exercitie resulteert veelal in de in tabel 2 vermelde voor accountants relevante IT-componenten.

C-2007-3-Kornelisse-t2

Tabel 2. IT-componenten in de IT-omgeving.

Auditdoelstellingen

Mede dankzij SOx zijn IT-auditors onderling meer consistent in het controleren van IT-aspecten bij een jaarrekeningcontrole. Navolgend wordt per IT-aspect betreffende de jaarrekeningcontrole uitgewerkt welke de relatie is met technische IT-beveiliging en wat de aan technische IT-beveiliging te stellen eisen zijn.

C-2007-3-Kornelisse-t3

Tabel 3. IT-relevante aspecten en beheersing.

Operationele risicobeheersing van de geautomatiseerde gegevensverwerking

De IT-omgeving van een organisatie dient aantoonbaar te worden beheerst.

C-2007-3-Kornelisse-3

Figuur 3. Inrichting van IT-beveiliging.

Voor de technische IT-beveiliging resulteert dit in vereisten als beveiligingsstandaarden (baselines) voor IT-componenten en de monitoring van het gebruik van deze standaarden, zowel bij de initiële implementatie van een IT-component als periodiek ter controle van de continue naleving.

In de praktijk is het veelal niet mogelijk een beveiligingsstandaard integraal toe te passen. In een dergelijke situatie dient de afwijking op de beveiligingsstandaard te worden gedocumenteerd en dient de passende managementlaag deze afwijking te accepteren, tijdelijk of permanent.

Borgen van functiescheidingen

Door een organisatie dienen diverse functiescheidingen te worden gedefinieerd en te worden geïmplementeerd. In figuur 4 is een aantal van deze functiescheidingen gepresenteerd.

C-2007-3-Kornelisse-4

Figuur 4. Vereiste functiescheidingen.

Er is al aangegeven dat een organisatie gebruik kan maken van baselines om adequate technische IT-beveiliging te realiseren. Het realiseren van functiescheidingen stelt eisen aan de mate van technische IT-beveiliging, die met de gedefinieerde baselines kan worden bewerkstelligd.

Gescheiden omgevingen voor Ontwikkeling, Test, Acceptatie en Productie (OTAP)

Omtrent OTAP dienen eisen te worden gesteld aan de scheiding van de verschillende OTAP-omgevingen. Immers, OTAP-omgevingen kunnen op verschillende niveaus worden gescheiden. Een aantal voorbeelden:

  • gescheiden netwerken;
  • gescheiden applicatieservers;
  • gescheiden databaseservers.

Tegenwoordig kunnen deze scheidingen zowel fysiek als virtueel worden gerealiseerd.

Daarnaast is het van belang dat programmatuur en (test)gegevens veilig worden overgedragen tussen de verschillende OTAP-omgevingen. Immers, een ontwikkelaar hoort hierbij geen toegang te hebben tot de acceptatie- en de productieomgeving. Geautomatiseerde hulpmiddelen kunnen hierbij uitkomst bieden.

Borgen van kantoorautomatisering

Elke organisatie maakt op haar eigen wijze gebruik van kantoorautomatisering voor het beheersen van de financiële stromen en de financiële rapportage. Denk hierbij aan goedkeuringen voor transacties via e-mail, opslag van belangrijke gegevens op fileservers, het gebruik van spreadsheets voor consolidatiedoeleinden en dergelijke.

De IT-auditor dient dan ook na te gaan of wordt gesteund op de kwaliteit van kantoorautomatisering betreffende de financiële stromen en de financiële rapportage. Indien dit zo is, dient kantoorautomatisering in de scope van het onderzoek te worden opgenomen, en dienen bijvoorbeeld file- en mailservers, evenals de werkplekken van (een deel van de) medewerkers te worden onderzocht ten aanzien van de technische IT-beveiliging.

Normen technische IT-beveiliging

Gegeven de onderkende IT-componenten worden de volgende normen voorgesteld:

Systeemconfiguratie-instellingen

Het is eenvoudig te stellen dat relevante systeemconfiguratieparameters adequaat dienen te zijn ingesteld. Het is dan ook belangrijk te definiëren welke parameters ten minste aan de orde zijn. In een beveiligingsstandaard dienen deze parameters te zijn vastgelegd. Bij het vaststellen van een beveiligingsstandaard dient tevens rekening te worden gehouden met de overkoepelende beveiligingsarchitectuur.

In tabel 4 zijn de voornaamste normen aangeduid. Let erop dat deze specifiek voor een organisatie dienen te worden gemaakt.

C-2007-3-Kornelisse-t4

Tabel 4. Normen voor de beoordeling van systeemconfiguratie-instellingen. [Klik hier voor grotere afbeelding]

Werkwijze

Op basis van het voorgaande resteert de vraag, hoe per gestelde norm de relevante zekerheid kan worden verkregen. De wijze van informatievergaring wordt navolgend uiteengezet.

Controle van de opzet van technische IT-beveiliging

Voor het controleren van de opzet van technische IT-beveiliging dienen de volgende testwerkzaamheden te worden uitgevoerd:

  • Scope
    • Vraag naar en inspecteer de IT-beveiligingsarchitectuur van de organisatie. Stel vast dat passende generieke IT-componenten in de scope van de IT-beveiligingsarchitectuur zijn opgenomen. Beoordeel hiertoe de locaties van IT-applicaties en data, en stel vast of de paden van eindgebruikers en beheerders naar IT-applicaties en data aanleiding geven om generieke IT-componenten in de scope op te nemen.
  • Beveiligingsstandaarden
    • Inspecteer voor de binnen de scope vallende IT-componenten de aanwezige beveiligingsstandaarden, en stel vast of de gedefinieerde maatregelen betreffende technische IT-beveiliging adequaat zijn, gegeven de auditdoelstellingen.

      Inspecteer in het bijzonder voor IT-applicaties de beveiligingsstandaarden voor selectie en ontwikkeling van veilige IT-applicaties.
    • Inspecteer documentatie inzake het goedkeuren van afwijkingen van beveiligingsstandaarden, en stel vast dat deze door een passend managementniveau worden geaccordeerd, tijdelijk of permanent.
    • Inspecteer documentatie inzake monitoring betreffende compliance aan beveiligingsstandaarden, zowel bij initiële implementatie in de productieomgeving als periodiek na het in productie nemen, en stel vast op welke wijze eventueel aanwezige afwijkingen op beveiligingsstandaarden worden gezocht en of eventuele afwijkingen door de organisatie zelf worden onderkend.
  • Logging
    • Inspecteer documentatie inzake monitoring betreffende gebeurtenissen in relatie tot IT-componenten, en stel vast dat relevante gebeurtenissen op adequate wijze zijn gedefinieerd en dienen te worden gedetecteerd.
Controle van de werking van technische IT-beveiliging

Voor het controleren van de werking van technische IT-beveiliging dienen de volgende testwerkzaamheden te worden uitgevoerd:

  • Indien de organisatie beveiligingsstandaarden systematisch hanteert, observeer dan een aantal IT-componenten van elk relevant type component (bijvoorbeeld SAP, Oracle, Windows, Unix, Cisco router, Checkpoint Firewall-1), en stel vast dat de systeemconfiguratie adequaat is ingesteld.
  • Indien een organisatie beveiligingsstandaarden niet systematisch hanteert, dan dienen alle relevante IT-componenten integraal (gegevensgericht) te worden onderzocht.

Het controleren van de systeemparameterinstellingen van een IT-component vraagt veel tijd en is foutgevoelig. Steeds vaker wordt dan ook auditprogrammatuur ingezet om dergelijke instellingen op te vragen. Ook worden steeds vaker penetratietests uitgevoerd om een indicatie te krijgen van de effectiviteit van technische IT-beveiliging.

Evaluatie van deficiënties

Op basis van de geconstateerde deficiënties betreffende de opzet en de werking van maatregelen dient te worden geëvalueerd welke beheersingsmaatregelen niet adequaat zijn gerealiseerd. Deze maatregelen kunnen bijvoorbeeld betrekking hebben op:

  • de operationele risicobeheersing, betreffende beschikbaarheid, integriteit en vertrouwelijkheid van de (geautomatiseerde) gegevensverwerking;
  • het borgen van functiescheidingen ten aanzien van de IT-omgeving;
  • het borgen van gescheiden omgevingen voor Ontwikkelen, Test, Acceptatie en Productie;
  • het borgen van functiescheidingen binnen de programmatuur;
  • het borgen van beschikbaarheid, integriteit en vertrouwelijkheid van kantoorautomatisering (bijvoorbeeld file- en mailservers).

In overleg met de accountant dient op basis van risico-overwegingen de impact van het eventueel doorbreken van deze beheersingsmaatregelen verder te worden beoordeeld in relatie tot de uitkomst van de financiële controle door de accountant.

Tot slot

Bij IT General Controls gaat de aandacht veelal uit naar de IT-beheerprocessen die ten grondslag liggen aan de integriteit en de beschikbaarheid van IT-applicaties en hierdoor verwerkte gegevens. Hiertoe zijn normenstelsels beschikbaar, onder andere gebaseerd op Cobit.

Het onderzoeken van technische IT-beveiliging in het kader van de jaarrekeningcontrole vraagt echter om meer complexe en minder routinematige activiteiten, zoals:

  • scoping van relevante IT-componenten, met name het vaststellen van de generieke IT-componenten naast de applicatiespecifieke IT-componenten, rekening houdende met de organisatiespecifieke beveiligingsarchitectuur van de IT-infrastructuur;
  • inspecteren van baselines betreffende diverse typen van beveiligingsstandaarden, bijvoorbeeld Windows, SAP, Oracle, Unix, Cisco IOS, Checkpoint Firewall-1. De kennis van elk van deze IT-componenten is veelal niet bij één persoon te vinden, ook niet bij een IT-auditor;
  • observeren van de feitelijke implementatie van IT-componenten en daarnaast het evalueren van de risico’s van afwijkingen van baselines in relatie tot een jaarrekening. Het eerste is niet eenvoudig, en het tweede is nog complexer.

Deze complexiteit neemt toe als gevolg van het onderzoeken van de werking van technische IT-beveiliging. Hierbij is het noodzakelijk op basis van het geconstateerde risicoprofiel van IT-applicaties in meerdere of mindere mate waarnemingen te verrichten betreffende de inrichting van de IT-componenten.

Gegeven het uitgebreide werkgebied van de IT-auditor mag niet worden verondersteld dat elke IT-auditor alle relevante kennis en ervaring inzake technische IT-beveiliging als bagage heeft. Indien een algemene IT-auditor de technische IT-beveiliging dient te beoordelen, is het dan ook van belang de eigen dekking van gevraagde kennis en ervaring expliciet in te schatten en waar nodig een technical IT-auditor in te schakelen. Afhankelijk van de omvang van de organisatie en in het bijzonder die van de IT-omgeving van de organisatie dient de inzet van laatstgenoemde nader te worden bepaald.

Bij diverse jaarrekeningcontroles van grotere organisaties wordt dit reeds onderkend en richt de algemene IT-auditor zich met name op IT-governance en IT-applicaties. De technical IT-auditor richt zich vervolgens op IT general controls en IT security binnen de rekencentra van deze organisaties.

Literatuur

[Ccg03] Commissie corporate governance, De Nederlandse corporate governance code, 9 december 2003.

[Korn05] Ir. P. Kornelisse RE CISA, R.P.J. van den Berg RA en A.A. van Dijke, SOx – de ICT aantoonbaar in control, Compact 2005/3.

[Korn06] Ir. P. Kornelisse RE CISA en H. IJkel RE CISA CISSP, Een inleiding tot integrated audit, Compact 2006/2.

[SEC03] US Securities and Exchange Commission, Final Rule: Management’s Reports on Internal Control Over Financial Reporting and Certification of Disclosure in Exchange Act Periodic Reports, Release Nos. 33-8238; 34-47986; IC-26068; File Nos. S7-40-02; S7-06-03, USA, June 2003.