General IT Controls in 2 bedrijven (deel 1)

Ieder jaar controleert een externe accountant de jaarrekening van de gemeente. Onderdeel van deze controle is een IT-audit die dient aan te tonen in hoeverre de ‘General IT Controls’ in opzet, bestaan en werking toereikend zijn. In deze blog zet ik uiteen wat de ‘General IT Controls’ zijn, bezien vanuit de controle op de jaarrekening. Ik leg ook de link naar de ISO27002 (BIO). De centrale vraag is: wat zijn ‘General IT Controls’ (GITC’s), en wat wordt er op dit gebied precies verwacht in de context van de jaarrekeningcontrole?

Achtergrond

De Gemeentewet schrijft voor dat elke gemeente jaarlijks begrotings- en verantwoordingsstukken moet opstellen, waaronder de jaarrekening. Het Besluit begroting en verantwoording provincies en gemeenten (BBV) bevat de regelgeving daarvoor. Ten behoeve van het opstellen van de verantwoordingsstukken in het kader van de jaarrekeningcontrole stelt de accountant o.m. vast in hoeverre de betrouwbaarheid van financiële gegevens is gewaarborgd en in hoeverre de genomen maatregelen effectief zijn in het voorkomen of tijdig detecteren van fouten en fraude.

Hiervoor wordt, onder verantwoordelijkheid van de accountant, onder meer een IT-audit uitgevoerd naar de GITC’s rondom informatiesystemen die relevant zijn voor de totstandkoming van de jaarrekening. Denk hierbij bijvoorbeeld aan primaire registratiesystemen, het administratiesysteem en betaalsystemen. GITC’s zijn de algemene beheersingsmaatregelen in de database en het besturingssysteem van de financiële applicatie, het netwerk, de beheerorganisatie en de autorisaties van beheerders. Deze GITC’s zijn randvoorwaarden voor een betrouwbare gegevensverwerking.

General IT-controls (GITC) en de jaarrekeningcontrole

De veiligheid, integriteit en betrouwbaarheid van financiële informatie – die centraal staat bij de audit als onderdeel van de jaarrekeningcontrole – valt of staat (vooral) met de juiste maatregelen voor toegang tot gegevens (gebruikers- of autorisatiebeheer), wijzigingsbeheer en continuïteit. Tekortkomingen op GITC’s kunnen vanzelfsprekend van uiteenlopende ernst zijn. De accountant zal zich ten behoeve van de jaarrekeningcontrole vooral richten op de GITC’s die samenhangen met potentieel grote risico’s t.a.v. de verwerking van financiële gegevens. In hoeverre GITC’s te implementeren hangt samen met risico’s: beheersing van autorisaties is strikter wanneer gebruikers omvangrijke financiële handelingen kunnen uitvoeren, wijzigingen in het informatiesysteem test je grondiger wanneer de impact hoger is en back-ups maak je vaker wanneer het zeer gevoelige gegevens betreft.

Door steeds te kijken naar de relatie met het financiële proces (en: financiële gegevens) kan je goed onderbouwen dat maatregelen ‘passend’ zijn. Om te komen tot een oordeel over de effectiviteit van de beheersing van GITC’s zal een IT-auditor:

Opzet beoordelen: is de beheersmaatregel beschreven in een (formeel/vastgesteld) document?
Bestaan testen: is de beheersmaatregel in de praktijk aantoonbaar geïmplementeerd volgens de opzet (op één moment)?
Werking toetsen: idem aan bestaan, maar dan bij iedere relevante gebeurtenis over een bepaalde periode. Bijvoorbeeld 6 maanden (i.p.v. één moment). Dus heb je 30 autorisatiewijzigingen dan heb je daar 30 keer de hele bewijsstukken-serie van die daarbij hoort.

Tips om je in het algemeen goed voor te bereiden op een audit lees je in deze eerdere blog. Nu gaan we eerst dieper in op de logische toegangsbeveiliging. Wijzigingsbeheer en continuïteit behandel ik de volgende keer.

Logische toegangsbeveiliging

Bij logische toegangsbeveiliging gaat het om maatregelen rond het toekennen, aanpassen en intrekken van autorisaties (IDU, In-, Door- en Uitstroom), het tegengaan van te veel autorisaties, groeps- en beheerdersaccounts tot een minimum beperken en een periodieke review van autorisaties. De gemeente moet voorkomen dat mensen financiële gegevens kunnen verwerken wat ze niet mogen vanuit hun functie (in het extreemste geval leidt dit tot fraude). Toegang wordt verstrekt op basis van het ‘need-to-know’ principe.

Hieronder worden de diverse aspecten van logische toegangsbeveiliging nader toegelicht. Per punt staat grofweg benoemd welke bewijslast benodigd is (t.b.v. de aantoonbaarheid) en welke maatregelen uit de ISO27002 hier betrekking op hebben.

  1. Procedure autorisatiebeheer
    Rechten worden toegekend aan een persoon op basis van een rol of een functie. Welke rechten behoren tot een rol of functie moet zijn vastgelegd in een autorisatiematrix. Daarin staan alle gebruikers opgenomen en hun individuele rechten (bij autorisatie op persoon) of anders hun rol/functie. Bij de twee laatstgenoemde heb je ook een overzicht nodig van de rechten binnen het informatiesysteem, per rol/functie. Voor alle drie de vormen van autoriseren dien je functiescheiding voldoende te borgen (minimaal 4-ogen principe) in overleg met business control.

    Deze gewenste situatie, zoals vastgelegd in de autorisatiematrix, wordt de SOLL genoemd. De werkelijke situatie, dus de feitelijke rechten, wordt de IST genoemd. De SOLL en de IST lopen constant uiteen en om de IST steeds opnieuw in overeenstemming te brengen met de SOLL dient er een o.a. beheerst proces voor autorisatiebeheer te zijn.

    In de procedure autorisatiebeheer zet je uiteen welke processtappen er (verplicht) doorlopen worden alvorens een gebruiker (de juiste) autorisaties toegekend krijgt binnen een informatiesysteem. Het is dus zaak dat in de procedure autorisatiebeheer nadrukkelijk de link wordt gelegd naar de autorisatiematrix. Anders gezegd: de IST moet steeds weer in overeenstemming worden gebracht met de SOLL. We moeten kunnen aantonen dat toegang (autorisatie) wordt verstrekt, gemuteerd en ingetrokken op basis van een beheerst proces. Van elke gebruiker moet dus aantoonbaar zijn dat de procedure (tijdig) gevolgd is. Het ligt voor de hand dat uitsluitend de leidinggevende aan aanvraag voor autorisaties kan indienen/goedkeuren. Dit zal doorgaans zijn bij het team functioneel beheer van het betreffende informatiesysteem.

    De procedure zet de stappen uiteen, de opgeslagen (ondertekende) autorisatie(aanvraag)formulieren tonen aan dat er conform de procedure wordt gewerkt en de autorisatiematrix geeft inzicht in de relatie tussen personen en rechten binnen het informatiesysteem.

    Benodigde bewijslast: procedure autorisatiebeheer, ondertekende autorisatieformulieren, autorisatiematrix (incl. ‘0-matrix’ met link tussen rol/functie en rechten bij autorisatie op persoon o.b.v. een voorbeeldgebruiker).
    Relatie ISO-maatregelen: 9.2.1, 9.2.2, 9.2

  2. Periodieke review autorisaties
    Om te bewerkstelligen dat de autorisaties binnen een informatiesysteem altijd kloppen – alle gebruikers hebben niet te veel en niet te weinig rechten – dient de systeemeigenaar periodiek een review uit te (laten) voeren. Deze periodieke review draagt eraan bij dat de IST in overeenkomst komt/blijft met de SOLL. De frequentie waarin dat gebeurt hangt nauw samen met de risicoclassificatie van het proces c.q. het informatiesysteem. In de context van de controle op de jaarrekening kijk je daarbij vanuit het oogpunt van het financiële proces, en niet primair vanuit de vertrouwelijkheid van gegevens.
    Hoe je dit volgordelijk aanpakt schrijf je op in een procedure. Zorg dat je ook minimaal jaarlijks de autorisatiematrix zelf bespreekt met de systeemeigenaar en desgewenst aanpast. Immers, de relatie tussen rechten en rol/functie moet wel blijven kloppen. Anders gezegd: de autorisatiematrix dient een accurate representatie van SOLL (intentie) te zijn én blijven.

    De persoon die de autorisaties aanvraagt voor een gebruiker is tevens de persoon die periodiek dient te (laten) controleren of de autorisaties nog kloppen. We gaan voor nu uit van een teamleider. Het ligt voor de hand daarvoor de gebruikers te exporteren en op te knippen in sub-lijstjes per teamleider (of vergelijkbaar). De teamleider bekrachtigt al dan niet per periode of het lijstje nog klopt, en zo niet wat er gecorrigeerd dient te worden. Afwijkingen worden vervolgens als beveiligingsincident afgehandeld.

    Benodigde bewijslast: procedure review autorisaties, (periodieke) goedkeuringen van teamleiders op gebruikers én hun corresponderende rechten, recent vastgestelde autorisatiematrix en een overzicht van afwijkingen in de autorisaties (incidentregistratie).
    Relatie ISO-maatregelen: 9.2.5, 9.4.1

  3. Identificatie (incl. groepsaccounts)
    Verwerkingen in financiële systemen moeten herleidbaar zijn naar een persoon. Het inrichten van een degelijk, beheerst proces van autorisatiebeheer (punt 1) en een periodieke review van de toegekende autorisaties (punt 2) heeft alleen zin wanneer je voldoende zekerheid hebt dat gebruikers zijn wie ze zeggen dat ze zijn bij het inloggen. Daarvoor dient identificatie: iedere gebruiker dient een unieke gebruikersnaam te hebben in het informatiesysteem. Je kan ook gebruikers hebben in een informatiesysteem met een status als ‘inactief’, ‘geblokkeerd’ of ‘uit dienst’. Strikt bezien zijn ook dat (nog) gebruikers.

    Persoonsgebonden accounts zijn nadrukkelijk het uitgangspunt. Voor handelingen in het financiële proces zijn niet herleidbare (groeps)accounts een no-go, op informatiesysteemniveau of in raadpleegrollen is er ruimte. Leg dit alles goed vast.

    Voor beheerders (zie punt 5) kan het handig zijn met groepsaccounts te werken. Leg de motivatie daartoe goed vast. Ook hier: niet meer dan noodzakelijk. Beheerders hebben vaak accounts in meerdere omgevingen uit ‘de OTAP-straat’. Zorg ervoor dat een beheerder niet met één en hetzelfde account kan inloggen in meerdere omgevingen. Scheid de Ontwikkel- van de Test-, Acceptatie- en Productieomgeving.

    Benodigde bewijslast: actueel overzicht van alle gebruikers(accounts) in het informatiesysteem inclusief status en, indien van toepassing, een degelijke onderbouwing indien er generieke accounts (groepsaccounts/ beheeraccounts) voorkomen in dit overzicht.
    Relatie ISO-maatregelen: 9.1.1, 9.1.2, 9.4.2

  4. Authenticatie (incl. logging)
    De tweede stap in het vaststellen van iemand identiteit is authenticatie. Mensen dienen niet alleen een eigen, unieke gebruikersnaam te hebben per informatiesysteem, maar ook een wachtwoord waarmee ze zich kunnen authentiseren. Na identificatie en authenticatie volgt autorisatie conform de autorisatiematrix. Log op z’n minst informatie rond de laatst geslaagde of mislukte inlogpoging per gebruikersaccount (incl. IP-adres/ werkstation).

    Aan wachtwoorden worden eisen gesteld om te voorkomen dat een ander relatief eenvoudig kan inloggen onder een gebruikersnaam die hem/haar niet toebehoort. Tijdelijke wachtwoorden dienen bij eerste gebruik (verplicht) te worden aangepast. Een wachtwoord voor Windows (AD-account) is bijvoorbeeld minimaal twaalf karakters lang en bevat minimaal één hoofdletter, minimaal één kleine letter, minimaal één cijfer en minimaal één bijzonder leesteken. Wachtwoorden zijn, afhankelijk van de classificatie van het informatiesysteem, maximaal 60 dagen geldig en mogen niet binnen zes keer herhaald worden. Vermoedelijk is een dergelijk wachtwoordbeleid tenminste van toepassing verklaard op informatiesystemen met een rol in het financiële proces.

    Het loggen van inlogpogingen stelt je o.a. in staat te monitoren op inactieve accounts. Indien er 3 maanden of langer geen gebruikt is gemaakt van een account, dient het account geblokkeerd te worden (met mededeling aan de hiërarchisch leidinggevende). Je kan dit zien als een geautomatiseerde variant van hetgeen beschreven staat onder punt 2.

    Benodigde bewijslast: wachtwoordbeleid, wachtwoord policy van het informatiesysteem, logs waaruit tenminste de laatste inlogpoging blijkt plus het IP-adres/ het werkstation en een actueel overzicht van accounts die inactief zijn gemaakt.
    Relatie ISO-maatregelen: 9.3.1, 9.4.2, 9.4.3

  5. ‘Superusers’ en beheerdersaccounts
    Superusers en beheerders hebben (bewust) meer rechten dan reguliere gebruikers. Deze extra rechten zijn nodig voor het uitvoeren van (beheer)werkzaamheden, maar introduceren tegelijk een risico. Immers, bij dergelijke accounts wordt het principe van functiescheiding geschaad. Het is daarom zaak het aantal dergelijke accounts tot een noodzakelijk minimum te beperken. In aanvulling op punt 3 kan je ervoor kiezen, afhankelijk van het risico dat samenhangt met de beheeraccount(s), voor deze accounts de logs intensiever te controleren.

    Een persoon mag nimmer als reguliere gebruiker inloggen op een informatiesysteem onder een beheerdersaccount. Ofwel: indien een persoon zowel gebruiker als beheerder van een informatiesysteem is, dan heeft deze persoon dus ook twee accounts.

    Benodigde bewijslast: overzicht van beheeraccounts en bijbehorende rechten (middels de autorisatiematrix), onderbouwing bij de noodzakelijkheid van de beheeraccounts.
    Relatie ISO-maatregelen: 9.2.3, 9.2.4

Dit was deel 1 van het tweeluik over General IT-controls. De volgende keer ga ik dieper in op wijzigingsbeheer en continuïteit. Heb je naar aanleiding van deze blog aanvullende vragen of hulp nodig om op dit punt verder te komen binnen jouw gemeente? Neem dan gerust contact met ons op.


General IT Controls in 2 bedrijven (deel 2)
Legaal hacken binnen je gemeente? Alles over de pentest

Copyright © 2014 - 2019 IB&P B.V.
Onze algemene voorwaarden & privacyverklaring. Ook handig: de sitemap