General IT Controls in 2 bedrijven (deel 2)

Als de externe accountant de jaarrekening controleert is een IT-audit daar onderdeel van. Daarbij moet opzet, bestaan en werking van de ‘General IT Controls’ aangetoond worden. In mijn vorige blog heb ik uitgebreid stilgestaan bij het onderdeel logische toegangsbeveiliging. Het ging over autorisatiebeheer, identificatie, authenticatie, logging en administrator accounts. In dit laatste deel van het tweeluik sta ik stil bij wijzigingsbeheer en continuïteit. Lees verder in deel twee!

Wijzigingsbeheer

Naast logische toegangsbeveiliging is ook wijzigingsbeheer van belang. Wijzigingen kunnen immers nieuwe risico’s introduceren in informatiesystemen en daarmee ook risico’s in de (financiële) gegevens in dat systeem. Het is dus is zaak wijzigingen middels een beheerst proces door te voeren op de (productie)omgeving zodat het informatiesysteem en de daarin opgeslagen gegevens betrouwbaar zijn én blijven.

Het is allereerst van belang dat de toegang tot het doorvoeren van wijzigingen strikt beheerst wordt. De wijzigingen moeten geëvalueerd worden alvorens ze worden doorgezet naar de productieomgeving. Dit veronderstelt natuurlijk een scheiding in omgevingen, naar op z’n minst Test, Acceptatie en Productie. Het formeel (laten) goedkeuren van een wijziging, met een correcte functiescheiding, alvorens deze wordt doorgevoerd op de productieomgeving is een essentiële stap.

Tot slot, allicht ten overvloede, dienen er geen wijzigingen te worden doorgevoerd op de productieomgeving die niet het proces van wijzigingsbeheer hebben doorlopen.

Hieronder worden de twee belangrijkste aspecten van wijzigingsbeheer nader toegelicht. Per punt staat grofweg benoemd welke bewijslast benodigd is (t.b.v. de aantoonbaarheid) en welke maatregelen uit de ISO27001 hier betrekking op hebben.

  1. Procedure wijzigingsbeheer
    Deze procedure beschrijft alle te nemen processtappen voor het doorvoeren van een wijziging op de productieomgeving. Er dienen stappen in te staan beschreven over het documenteren, autoriseren, testen, evalueren en accepteren van wijzigingen. De procedure dient o.a. aandacht te schenken aan de verschillende betrokkenen bij het doorvoeren van een wijzigingen, inclusief hun bevoegdheid (bijv. tot het goedkeuren voor productie) en (tijdelijke) toegangsrechten. Hieruit moet ook af te leiden zijn of functiescheiding voldoende geborgd is.

    Er dient een complete registratie te zijn van alle uitgevoerde wijzigingen aan een informatiesystemen. Middels vastgelegde documentatie per stap in het proces van wijzigingsbeheer dient herleidbaar te zijn dat al deze stappen per wijzigingen doorlopen zijn Neem in je procedure ook uitzonderingsprocedure (‘spoedgevallen’) op voor die uitzonderlijke gevallen waarin de reguliere procedure niet kan worden gevolgd.

    Benodigde bewijslast: procedure wijzigingsbeheer, actuele registratie van doorgevoerde wijzigingen inclusief vastlegging diverse stappen (release notes, verslagen etc.)
    Relatie ISO-maatregelen: 12.1.2, 14.2.2

  2. Scheiding van IT-omgevingen (OTAP)
    Een beheerst proces van wijzigingsbeheer bestaat alleen wanneer en sprake is van tenminste een Test-, Acceptatie- en een Productieomgeving. De Ontwikkelomgeving is alleen van toepassing indien de gemeente zelf software ontwikkelt, maar er zijn ook situaties waarbij de Acceptatie- en Productieomgeving extern ‘staat’. Ontwikkelen vindt nimmer direct plaats in de productieomgeving. De diverse omgevingen dienen minimaal logisch van elkaar gescheiden te zijn. Dit houdt in dat de omgevingen onafhankelijk van elkaar bestaan en ze onderling niet te benaderen (acceptatie is bijv. IP 10.100.20.5/24 en productie 10.100.1.50/24).

    In dit IT-ontwikkelorganisatie dient sprake te zijn van functiescheiding. Dat houdt o.m. in dat ontwikkelaars standaard geen directe rechten hebben op de productomgeving. Ze kunnen dus geen wijzigingen doorvoeren zonder tussenkomst van de gebruikersorganisatie. Het houdt ook in dat (eind)gebruikers van het informatiesysteem niet beschikken over ontwikkelrechten.

    Om een softwareleverancier toegang te geven tot de productieomgeving heeft deze een account nodig. Zorg dat dit account standaard gedeactiveerd staat en alleen wordt geactiveerd wanneer de leverancier volgens een procedure toegang aanvraagt. Deze procedure dient ook te voorzien in het achteraf weer deactiveren van het account.

    Benodigde bewijslast: actuele (technische) beschrijving van de verschillende (OTAP) omgevingen, procedure voor het beheerst toegang verschaffen aan mogelijke softwareleverancier of externe beheerder.
    Relatie ISO-maatregelen: 9.4.2, 12.1.4

Continuïteit

Een betrouwbare informatievoorziening houdt o.m. in dat (financiële) informatiesystemen beschikbaar zijn wanneer ze nodig zijn. Daar hoort ook bij dat de systeemeigenaar maatregelen laat nemen ter voorbereiding op een verstoring in het informatiesysteem. In andere woorden: de continuïteit van het informatiesysteem (of eigenlijk: de dienstverlening) moet gewaarborgd zijn, ook in het geval van een incident of calamiteit. Dit is te bereiken door enerzijds maatregelen te nemen om de kans op verstoringen te verkleinen en anderzijds maatregelen te nemen om een verstoring adequaat af te kunnen handelen.

Het onderdeel continuïteit is op te delen in drie aspecten. Allereerst dienen er maatregelen te worden genomen in het fysieke domein. Servers en apparatuur dienen in een afgesloten (brandveilige) ruimte te staan, beschermd tegen waterschade, oververhitting en fluctuaties of uitval in de stroomvoorziening. Ten tweede dient er een back-upbeleid en een back-upschema te zijn welke, ten derde, ook periodiek getoetst dienen te worden. Je wilt immers dat de gegevens vanuit een back-up binnen de eisen van de bedrijfsvoering weer terug te zetten (restoren) zijn naar de productieomgeving.
Bij het aantonen van de betrouwbaarheid van informatiesystemen die gebruikt worden bij financiële processen ontkom je er dus niet aan, aan te tonen dat ook op het terrein van continuïteit voldoende maatregelen zijn genomen.

Hieronder worden de voornoemde vier aspecten van continuïteit nader toegelicht. Per punt staat grofweg benoemd welke bewijslast benodigd is (t.b.v. de aantoonbaarheid) en welke maatregelen uit de ISO27001 hier betrekking op hebben.

  1. Fysieke beveiliging
    Informatiesystemen kunnen ‘dichtbij’ draaien; in het datacenter van de gemeente of verder weg; in een (cloud)omgeving bij de leverancier. Uiteindelijk draait een informatiesysteem ergens op een server en die server staat ergens in een ruimte. Je wilt de kans op verstoringen verkleinen en dus voorzie je een dergelijk serverruimte van een brandmeld- en brandblusinstallatie, ventilatie/airco, UPS en een slot- of badgesysteem. Vanzelfsprekend richt je de toegangsrechten op deze ruimte zéér strikt in volgens een beheerst proces en log je de toegang(spogingen). Analoog aan de digitale toegang tot informatiesystemen dus. Afwijkingen worden ook hier als beveiligingsincident afgehandeld.

    Benodigde bewijslast: contract dienstverlening, SLA, verwerkersovereenkomst (bij persoonsgegevens en uitbesteding) relevante ISO-certificering en/of TPM-verklaring van de leverancier op de genoemde punten.
    Indien dat laatste (nog) niet haalbaar is, dan: beleid voor zonering en fysieke toegang, testrapporten diverse voorzieningen (zoals UPS) in de serverruimte, procedure fysieke toegang, actueel gebruikersoverzicht met toegang tot serverruimte, toegangsregistratie serverruimte en een overzicht van afwijkingen in de toegang (incidentregistratie).
    Relatie ISO-maatregelen: 11.1.1, 11.1.2, 11.1.3, 11.1.4, 15.1.1, 15.1.2, 15.2.1, 15.2.2

  2. Back-up oplossingen
    Om in het geval van verstoringen weer terug te kunnen keren naar de situatie van vóór de verstoring dienen back-ups gemaakt te worden. Eisen aan back-ups moeten duidelijk zijn. Volstaat één ‘generiek’ back-upbeleid of gelden er voor enkele informatiesystemen aanvullende eisen? Een vraag die je beantwoordt door, in dit geval, primair te kijken naar de relatie met het financiële proces en het daarmee samenhangende risico. Daaruit kan volgen dat het maximaal toelaatbare gegevensverlies (RPO) en/of de maximaal toelaatbare uitvalsduur (hersteltijd, RTO) lager liggen dan waar het generieke, gemeentebrede back-upbeleid vanuit gaat. Leg deze afweging vast. Het uitvoeren en het slagen/falen van back-ups wordt gemonitord en vastgelegd. Fouten worden geïdentificeerd en aantoonbaar gecorrigeerd.

    Benodigde bewijslast: contract dienstverlening, SLA, verwerkersovereenkomst (bij persoonsgegevens en uitbesteding) relevante ISO-certificering en/of TPM-verklaring van de leverancier op de genoemde punten.
    Indien dat laatste (nog) niet haalbaar is, dan: (generiek) back-upbeleid en back-upschema, formele risicoafweging per bedrijfsproces/informatiesysteem t.o.v. het generieke back-upbeleid plus eventuele aanvullende eisen (RPO, RTO), registratie van alle uitgevoerde back-ups (gelukt en mislukt) plus opvolging bij falen.
    Relatie ISO-maatregelen: 12.3.1, 15.1.1, 15.1.2, 15.2.1, 15.2.2

  3. Periodieke hersteltesten
    Het testen van de back-ups doe je op diverse niveaus: besturingssysteem (OS), database en informatiesysteem. De uitkomst van deze tests leg je vast zodat de testen (controles) aantoonbaar zijn. De frequentie van hersteltesten is minimaal jaarlijks, maar het risicoprofiel van het informatiesysteem (i.r.t. het financiële proces) kan nopen tot vaker testen. Een test is pas 100% succesvol wanneer de gebruikersorganisatie weer in de productieomgeving kan werken met het informatiesysteem en de informatie volledig conform de eisen (zie 2) is hersteld.

    Benodigde bewijslast: contract dienstverlening, SLA, verwerkersovereenkomst (bij persoonsgegevens en uitbesteding) relevante ISO-certificering en/of TPM-verklaring van de leverancier op de genoemde punten.
    Indien dat laatste (nog) niet haalbaar is, dan: procedure voor hersteltesten, risicoafweging over frequentie van hersteltesten indien niet standaard minimaal jaarlijks, actuele registratie van uitgevoerde hersteltesten, rapporten van hersteltesten waarmee aantoonbaar is in hoeverre de hersteltest(en) succesvol zijn uitgevoerd.
    Relatie ISO-maatregelen: 12.3.1, 15.1.1, 15.1.2, 15.2.1, 15.2.2

Dus.

Je hebt nu vast opgemerkt dat de IT-audit in de context van de jaarrekeningcontrole weliswaar over bekende onderwerpen gaat, maar toch andere accenten legt dan een ‘reguliere’ IT-audit. Wanneer je de DigiD/Suwi lat uit ENSIA voor de BIG/BIO op hetzelfde niveau legt, dan zal je weinig moeite hebben bij de IT-audit vanuit de jaarrekeningcontrole. Wel dien je veelal ook werking aan te kunnen tonen.
De realiteit is dat voor de BIG/BIO de lat níet op dat niveau ligt en dat lijkt me voorlopig ook niet haalbaar. Mijn advies: selecteer je kritische informatiesystemen, selecteer key controls uit de BIG/BIO (misschien de GITC’s? ;-)) en laat vanuit hier de beide IT-audits naar elkaar toe groeien.

Dit was het laatste deel in het tweeluik over General IT-controls. In deel 1 van deze reeks ben ik dieper ingegaan op logische toegangsbeveiliging. 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.

Risicomanagement; dichterbij dan je denkt?
General IT Controls in 2 bedrijven (deel 1)

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