Skip to main content

Risicoanalyse aan de hand van het MAPGOOD-model


Bij een risicoanalyse worden bedreigingen en risico’s benoemd en in kaart gebracht. Vaak is het voor organisaties lastig om vanuit het niets bedreigingen en risico’s op het gebied van informatiebeveiliging te benoemen. Een veel gebruikt model om dit proces te ondersteunen is het zogenaamde MAPGOOD-model. In deze blog leg ik uit hoe dit model werkt.

Risicoanalyse

Als gemeente wordt het aangeraden een baselinetoets uit te voeren. Hiermee bepaal je het Basisbeveiligingsniveau (BBN). Als de uitkomst van de baselinetoets als resultaat geeft dat BBN2 ontoereikend is, is een diepgaande risicoanalyse (DRA) nodig. Het doel van de DRA is om in kaart te brengen welke maatregelen aanvullend op de Baseline Informatiebeveiliging Overheid (BIO) moeten worden getroffen om het juiste beveiligingsniveau te realiseren. De DRA bestaat uit de volgende drie stappen:

  1. Het in kaart brengen van de onderdelen van de informatievoorziening volgens het MAPGOOD-model.
  2. Het in kaart brengen van de dreigingen die relevant zijn voor het te onderzoeken informatiesysteem, met per dreiging het potentiële effect en de kans op optreden.
  3. Het vertalen van de meest relevante dreigingen naar maatregelen die moeten worden getroffen.

Het MAPGOOD-model

Om bedreigingen en risico’s op het gebied van informatiebeveiliging in kaart te brengen, heb je inzicht nodig in de informatievoorziening van de gemeente. Om alle componenten van de informatievoorziening in kaart te brengen kan gebruik worden gemaakt van het MAPGOOD-model. MAPGOOD staat voor Mensen, Apparatuur, Programmatuur, Gegevens, Organisatie, Omgeving en Diensten. Het MAPGOOD-model biedt houvast om de risico’s met de systeemeigenaar te inventariseren. Zo zijn er verschillende invalshoeken die je kunt gebruiken om naar bedreigingen en risico’s te kijken om zo beveiligingsmaatregelen in kaart te brengen:

  • Mens – de mensen die nodig zijn om het informatiesysteem te beheren en gebruiken, denk aan: directe en indirecte gebruikers, en functioneel en technisch applicatiebeheer.
  • Apparatuur – de apparatuur die nodig is om het informatiesysteem te laten functioneren, denk aan: webserver, applicatieserver, beheer van werkplekken en werkplekken van gebruikers.
  • Programmatuur – de programmatuur waaruit het informatiesysteem bestaat, denk aan: de diverse applicaties die gebruikt worden.
  • Gegevens – de gegevens die door het systeem worden verwerkt, denk aan: basisregistraties, financiële verantwoording en vergunningen.
  • Organisatie – de organisatie die nodig is om het informatiesysteem te laten functioneren, denk aan: beheer-, gebruikers- en ontwikkelorganisatie.
  • Omgeving – de omgeving waarbinnen het informatiesysteem functioneert, denk aan: locatie, serverruimte en werkplekken.
  • Diensten – de externe diensten die nodig zijn om het systeem te laten functioneren, denk aan: technisch systeembeheer, netwerkinfrastructuur en onderhoudscontracten met externe dienstverleners.

Het is belangrijk om elk component zo volledig mogelijk te beschrijven. De systeemeigenaar kan ook de proceseigenaar (vaak lijnmanager) betrekken in dit proces. Hij/zij is immers verantwoordelijk voor zijn/haar afdeling. Hierbij hoeft uiteraard niet alles tot in details te worden beschreven, zoals schijfgrootte, hoeveelheid geheugen of beeldschermresolutie, maar volledigheid op hoofdniveau is wel belangrijk om later bedreigingen en maatregelen goed te kunnen toewijzen. Daarnaast moet er onderscheid gemaakt worden tussen de taken waar de systeemeigenaar direct voor verantwoordelijk is en de zaken die hij/zij heeft uitbesteed aan een externe partij. Deze vallen namelijk onder het component ‘Dienst’.

Omgaan met risico’s
Het MAPGOOD-model helpt je bij het inventariseren van de risico’s en bedreigingen, maar daarna ga je per onderdeel ook kijken naar wat de kans op optreden is en welke impact daarbij hoort. Kortom wat is de invloed (schade) ervan op de werking van het informatiesysteem? Daarna bepaal je hoe met het vastgestelde risico wordt omgegaan om zo dreigingen het hoofd te bieden. Dat kan op vier manieren:

  1. Vermijden – Je vermijdt het risico, bijvoorbeeld door het nemen van maatregelen.
  2. Verminderen – Je beperkt de gevolgen door het nemen van alternatieve maatregelen.
  3. Overdragen – Je draagt de risico’s over door een andere partij te betrekken, bijvoorbeeld door maatregelen op centraal niveau te nemen (in plaats van op proces/informatiesysteem).
  4. Accepteren – Op geen van de bovenstaande manieren kun je het risico aanpakken dus je accepteert het risico en neemt geen maatregelen.

Uiteraard is de manier waarop je omgaat met risico’s afhankelijk van de situatie binnen jouw gemeente. Ook is het binnen gemeenten niet altijd duidelijk wie verantwoordelijk is voor het uitvoeren van de risicoanalyse. Is dit de CISO, ISO of proceseigenaar? Wanneer je naar de BIO kijkt, wordt de taak van het uitvoeren van de risicoanalyse bij de proceseigenaar belegd. Het is dus wel belangrijk dat je als gemeente deze rol hebt toegekend met de juiste taken en verantwoordelijkheden.

Meer informatie?

In de handreiking ‘Diepgaande Risicoanalyse Methode Gemeenten’ van de Informatiebeveiligingsdienst voor gemeenten (IBD) vind je een uitgebreide toelichting inclusief templates en werkwijze voor het toepassen van het MAPGOOD-model. Heb je na het lezen van deze blog vragen of hulp nodig binnen jouw gemeente op dit vlak? Laat ons dit dan weten en neem contact met ons op.  

Erna Havinga

Lees ons boek

Gemeenten. Bewustzijn. Privacy.

Het handboek voor informatiebewustzijn bij de lokale overheid.

Training

Informatiebeveiliging en Privacy voor I-adviseurs en projectleiders

Schrijf je in voor de cursus op 7 en 14 november 2023 op ons kantoor in Zwolle, of neem contact op om een in-house cursus in te plannen!

Meer blogs lezen

Wat betekent de AI-verordening voor informatiebeveiliging bij gemeenten?

Het gebruik van AI neemt in rap tempo toe. Wat betekent dat voor je informatiebeveiliging als gemeente?

De 5 meest gemaakte fouten in verwerkersovereenkomsten

: Een van de belangrijkste eisen uit de AVG is het afsluiten van een verwerkersovereenkomst wanneer je persoonsgegevens door een externe partij laat verwerken. In de praktijk gaat dat echter nog vaak mis. Verwerkersovereenkomsten zijn te vaag, onv…

Veiligheid begint met inzicht: zo geef je kwetsbaarhedenbeheer vorm

Het is belangrijk om kwetsbaarheden niet ad hoc, maar structureel aan te pakken. Niet alleen binnen je eigen ICT-omgeving, maar ook daarbuiten. In deze blog leggen we uit wat kwetsbaarhedenbeheer is, waarom het zo belangrijk is en hoe je het goed …

Hoe interne audits leiden tot verbetering

Informatiebeveiliging en privacy zijn essentieel, vooral voor gemeenten die werken met gevoelige gegevens en kritieke processen. Risicobeheer, naleving van wetgeving en continue verbetering zijn hierbij onmisbaar. Naast IT- en security-experts spe…

Het algoritmeregister: Hoe gemeenten algoritmes verantwoord inzetten

Steeds meer gemeenten gebruiken algoritmes om hun werk efficiënter te maken. Handig, maar het brengt ook risico’s met zich mee voor privacy, veiligheid en transparantie. Daarom is er sinds 2022 een landelijk algoritmeregister. In deze blog lees je…

Waarom een DPIA onmisbaar is binnen gemeentelijke projecten

Vanuit de AVG en BIO moet je als gemeente allerlei (verplichte) maatregelen nemen. Zo moet je bij gegevensverwerkingen met een hoog privacyrisico een Data Protection Impact Assessment (DPIA) uitvoeren. In deze blog lees je wat een DPIA precies is …