Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Het omgaan en beheren van incidenten omvat een aantal activiteiten die, afhankelijk van de klasse waartoe de getroffen informatie behoort, al dan niet verplicht uitgevoerd moeten worden. Deze activiteiten zijn (zie https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.-De-bouwstenen-van-incident-beheer ):

  • Melden van een incident;

  • Toewijzen van een categorie aan het incident;

  • Impact van het incident bepalen;

  • Urgentie van het incident bepalen;

  • Registratie en documentatie van het incident;

  • Functionele escalatie;

  • Hiërarchische escalatie;

  • Communicatie van het incident;

  • Inperken van de gevolgen van het incident;

  • Uitvoeren van een work around;

  • Uitwerken van een permanente oplossing via wijzigingsbeheer;

  • Rapporteren van het incident;

  • Uitvoeren van lessons learned.

De minimale beschikbaarheid van het proces ‘incident beheer’ zelf is eveneens afhankelijk van het type en klasse van de getroffen informatie. We onderscheiden beschikbaarheid tijdens kantooruren (10ux5dagen) en permanente beschikbaarheid (24ux7dagen).

Melden van een incident

Deze activiteit betreft gebruikers die een incident opmerken, het gaat dus niet om systeem meldingen (deze komen via het proces ‘beheer van gebeurtenissen’ in het incident registratiesysteem). Voor het melden van incidenten moet een meldpunt voorzien worden. Dit kan een helpdesk/ servicedesk zijn, maar even goed een teamleider of ICT-correspondent (een ICT-medewerker of een gebruiker aangeduid om informatie over incidenten te verzamelen. Voor meer detail zie hoofdstuk: ‘Helpdesk/ servicedesk’.

Toewijzen van een categorie

Dit is besproken in hoofdstuk https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.1.-Registratie-en-categorisatie-van-het-incident .

Bepalen van de impact

Dit is besproken in hoofdstuk https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.2.-Prioriteit-bepalen-van-een-incident .

Bepalen van de urgentie

Dit is besproken in hoofdstuk https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.2.-Prioriteit-bepalen-van-een-incident .
Noteer dat impact en urgentie samen de prioriteit van het incident definiëren.

Registratie en documentatie van het incident

Met de registratie van een incident bedoelen we één of andere vorm van inschrijving. Daarnaast moet het incident ook gedocumenteerd worden. De eenvoudigste vorm is de registratie en documentatie in een logboek. Zo’n logboek kan bijgehouden worden door een afdeling of departement (decentraal) of centraal, al dan niet onder beheer van de incident manager. Voor de registratie, documentatie en opvolging van incidenten zijn diverse tools op de markt beschikbaar, maar deze zijn vaak duur en vereisen complexe installaties. Voor meer detail zie hoofdstuk https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.1.-Registratie-en-categorisatie-van-het-incident en hoofdstuk https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.5.-Documentatie-van-het-incident.

Functionele escalatie

Vaak worden dezelfde incidenten meerdere malen gemeld en opgelost. Indien de oplossing of work around gekend is door het meldpunt, is het niet nodig om anderen in te schakelen. Indien er geen oplossing of work around gekend is door het meldpunt, moeten één of meerdere technische specialisten zich buigen over het incident. Het incident wordt hierbij waar nodig opgesplitst in deelincidenten die naar de betrokken afhandelaars worden gestuurd. Voor meer detail zie https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.2.3.4.-Escalatie

Hiërarchische escalatie

Sommige incidenten moeten doorgestuurd worden naar de security officer (CISO), ICT-coördinator of DPO (functionaris gegevensbescherming) indien aanwezig, dit laatste met name als er persoonsgegevens betrokken (kunnen) zijn bij het incident. Deze zal niet als primaire afhandelaar optreden (het technisch verhelpen gebeurt niet door de CISO of DPO), maar moet wel geïnformeerd worden. Sommige incidenten vereisen een doorsturen naar het management, bijvoorbeeld wanneer de ernst van het incident zodanig hoog is of als er acties nodig zijn die de bevoegdheid van de betrokken medewerkers overstijgen.
Voor meer detail zie hoofdstuk: ‘Escalatie’.

Communicatie van het incident

Dit is besproken in hoofdstuk 'Communicatie van het incident'.

Inperken van de gevolgen van het incident

Dit is besproken in hoofdstuk: ‘Beperken van de schade’.

Uitvoeren van work around

Wanneer het incident niet kan snel genoeg kan worden opgelost, is het soms toch mogelijk om een work around oplossing voor te stellen. Dit betekent dat de oorzaak van het incident niet is weggenomen, maar dat er een werkwijze kan worden voorgesteld om aan de gebruiker toe te laten dezelfde of een gedeeltelijke (aanvaardbare) functionaliteit te gebruiken tot een permanente oplossing gevonden en geïmplementeerd is. Voor meer detail zie hoofdstuk: ‘Behandelen van het incident’.

Uitwerken van een permanente oplossing via wijzigingsbeheer

Een incident kan vaak enkel opgelost worden (wegnemen van de oorzaak, inperken van de gevolgen) door het uitvoeren van een wijziging. Dit kan een eenvoudige systeemwijziging zijn (een verandering in de configuratie) of de uitvoering/implementatie van een complexe oplossing. Een wijziging kan enkel uitgevoerd worden onder het proces ‘wijzigingsbeheer’ (voor meer informatie zie document: ‘Vo Informatieclassificatie - Minimale maatregelen – wijzigingsbeheer’). Voor meer detail zie hoofdstuk: ‘Behandelen van het incident’.

Rapporteren van het incident

Dit is besproken in hoofdstuk ‘Rapportering en evaluatie’.

Uitvoeren van lessons learned

Een lessons learned oefening houdt een evaluatie van de afhandeling van het incident in. Dit is geen beoordeling van het proces ‘incident beheer’, maar een evaluatie van het incident zelf. Had dit voorkomen kunnen worden? Zijn er wijzigingen of verbeteroplossingen in de toekomst nodig?

Een lessons learned kan resulteren in een verbetertraject. Dit kan een verstrenging van procedures inhouden, een bewustmakingscampagne, technische implementaties, … Wanneer zo’n verbetertraject een wijziging inhoudt, dan dient dit opgenomen te worden door het proces wijzigingsbeheer indien het verbetertraject effectief ingepland dient te worden, of door het proces release management indien het verbetertraject opgenomen dient te worden maar nog niet effectief ingepland kan worden (bvb omdat bepaalde infrastructuur nog ontbreekt, of de impact op performantie nog te groot is of …).
Het is van belang dat de lessons learned oefening snel na het afsluiten van het incident plaats vindt, zodat alles nog vers in het geheugen is.
Dit is besproken in hoofdstuk ‘Rapportering en evaluatie'.

4.5.2.1. Minimale algemene maatregelen

Vertrouwelijkheid

IC klasse 

Minimale maatregelen 

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Melden van een incident aan een meldpunt;

  • Toewijzen van een categorie aan het incident;

  • Impact van het incident: geen of lage impact;

  • Urgentie van het incident bepalen: dit is afhankelijk van het type of aantal getroffen gebruikers of systemen;

  • Registratie en documentatie van het incident minimaal in een logboek;

  • Functionele escalatie indien het meldpunt het incident niet kan oplossen;

  • Escalatie naar management van incidenten met prioriteit P1;

  • Communicatie van het incident naar de getroffen gebruikers;

  • Inperken van de gevolgen van het incident;

  • Uitvoeren van een work around indien beschikbaar;

  • Uitwerken van een permanente oplossing en deze indienen als wijziging indien beschikbaar;

  • Rapporteren van het incident;

  • Uitvoeren van lessons learned voor incidenten met prioriteit P1 na afsluiten van het incident

Alle maatregelen van Klasse 1 / Klasse 2 +

  • Impact van het incident: minimaal medium (want er is materiële schade mogelijk);

  • Urgentie van het incident bepalen: dit is afhankelijk van het type of aantal getroffen gebruikers of systemen maar minimaal medium;

  • Registratie van het incident in een centraal logboek onder beheer van een incident manager;

  • Escalatie naar CISO/ ICT-coördinator;

  • Uitvoeren van lessons learned na afsluiten van het incident.

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +

  • Impact van het incident: minimaal medium (want er is materiële schade mogelijk);

  • Urgentie van het incident bepalen: dit is afhankelijk van het type of aantal getroffen gebruikers of systemen maar minimaal medium;

  • Registratie van het incident in een centraal logboek onder beheer van een incident manager;

  • Escalatie naar CISO/ ICT-coördinator;

  • Uitvoeren van lessons learned na afsluiten van het incident.

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +

  • Impact van het incident: hoge impact (want ernstige materiële schade mogelijk);

  • Urgentie van het incident: altijd hoog;

  •  Escalatie naar management van elk incident.

Integriteit

IC klasse 

Minimale maatregelen 

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Melden van een incident aan een meldpunt;

  • Toewijzen van een categorie aan het incident;

  • Impact van het incident: geen of lage impact;

  • Urgentie van het incident bepalen: dit is afhankelijk van het type of aantal getroffen gebruikers of systemen;

  • Registratie en documentatie van het incident minimaal in een logboek;

  • Functionele escalatie indien het meldpunt het incident niet kan oplossen;

  • Escalatie naar management van incidenten met prioriteit P1;

  • Communicatie van het incident naar de getroffen gebruikers;

  • Inperken van de gevolgen van het incident;

  • Uitvoeren van een work around indien beschikbaar;

  • Uitwerken van een permanente oplossing en deze indienen als wijziging indien beschikbaar;

  • Rapporteren van het incident;

  • Uitvoeren van lessons learned voor incidenten met prioriteit P1 na afsluiten van het incident.

Alle maatregelen van Klasse 1 / Klasse 2 +

  • Impact van het incident: minimaal medium (want er is materiële schade mogelijk);

  • Urgentie van het incident bepalen: dit is afhankelijk van het type of aantal getroffen gebruikers of systemen maar minimaal medium;

  • Registratie van het incident in een centraal logboek onder beheer van een incident manager;

  • Escalatie naar CISO/ ICT-coördinator;

  • Uitvoeren van lessons learned na afsluiten van het incident.

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +

  • Impact van het incident: minimaal medium (want er is materiële schade mogelijk);

  • Urgentie van het incident bepalen: dit is afhankelijk van het type of aantal getroffen gebruikers of systemen maar minimaal medium;

  • Registratie van het incident in een centraal logboek onder beheer van een incident manager;

  • Escalatie naar CISO/ ICT-coördinator;

  • Uitvoeren van lessons learned na afsluiten van het incident.

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +

  • Impact van het incident: hoge impact (want ernstige materiële schade mogelijk);

  • Urgentie van het incident: altijd hoog;

  • Escalatie naar management van elk incident

Beschikbaarheid

IC klasse 

Minimale maatregelen 

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Beschikbaarheid van het proces incidentbeheer is minimaal kantooruren (5d x 10u)

Klasse 3, Klasse 4 en Klasse 5 kennen dezelfde maatregelen:

Alle maatregelen van Klasse 1 / Klasse 2 +

  • Beschikbaarheid van het proces incidentbeheer is minimaal kantooruren (24u x 7d)

1.2. Minimale specifieke (GDPR) maatregelen

De minimale algemene maatregelen voor incidentbeheer moeten toegepast worden: per klasse zijn de overeenkomende maatregelen van toepassing (zie hoofdstuk 'minimale algemene maatregelen').

Vertrouwelijkheid en integriteit

IC klasse 

Minimale maatregelen 

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

  • Escalatie naar CISO/ ICT-coördinator of DPO;

    • Communicatie van het incident naar de getroffen burgers volgens de criteria van GDPR

Alle maatregelen van Klasse 1 / Klasse 2 +

  • Escalatie naar DPO indien aanwezig;

  • Communicatie van het incident naar de getroffen gebruikers en eventueel VTC (volgens de criteria van VTC);

  • Uitvoeren van lessons learned na afsluiten van het incident en met verplicht verbetertraject via release management

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +

  • Impact van het incident: hoge impact (want hoge materiële en/of lichamelijke schade mogelijk);

  • Escalatie naar management van incidenten met prioriteit P1 of P2

Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +

  • Impact van het incident: hoge impact (want ernstige materiële en/of lichamelijk schade mogelijk).

Beschikbaarheid

Er zijn geen GDPR specifieke maatregelen gedefinieerd in het kader van beschikbaarheid.

1.3. Minimale specifieke (NIS II) maatregelen

In afwachting van de goedkeuringen omtrent NISII is er in dit document alvast de nodige ruimte voorzien voor toekomstige minimale specifieke NISII maatregelen.

1.4. Minimale specifieke (KSZ) maatregelen

Volgens de Minimale Normen van de Kruispuntbank Sociale Zekerheid moeten volgende maatregelen in het kader van incidentbeheer toegepast worden:

Vertrouwelijkheid en integriteit

IC klasse 

Minimale maatregelen 

Klasse 1, Klasse 2, Klasse 3, Klasse 4 en Klasse 5 kennen dezelfde maatregelen: 

Elke organisatie moet:

  • a. procedures hebben voor het vastleggen en beheren van incidenten over informatieveiligheid of privacy en de bijhorende verantwoordelijkheden. Deze procedures moeten bekend zijn bij alle medewerkers.

  • b. Vastleggen in de overeenkomst met de medewerkers dat elke medewerker (zowel vast of tijdelijk, intern of extern) verplicht is melding te maken van  ongeautoriseerde toegang, gebruik, verandering, openbaring, verlies of vernietiging van informatie en informatiesystemen.

  • c. Gebeurtenissen en zwakheden over informatieveiligheid of privacy die verband houden met informatie en informatiesystemen van de organisatie zodanig kenbaar maken dat de organisatie tijdig en adequaat corrigerende maatregelen kan nemen. 

  • d. Incidenten over informatieveiligheid en privacy zo snel als mogelijk via de leidinggevende, de helpdesk, de informatieveiligheidsconsulent (CISO) of functionaris van gegevensbescherming (DPO) rapporteren.

  • e. Bij incidenten over informatieveiligheid of privacy het bewijsmateriaal in overeenstemming met wettelijke en regelgevende voorschriften correct verzamelen.

  • f. Elk incident over informatieveiligheid of privacy formeel evalueren opdat procedures en controlemaatregelen verbeterd kunnen worden. De lessen die getrokken worden uit een incident dienen gecommuniceerd te worden naar de directie van de organisatie voor validatie en goedkeuring van verdere acties.

  • g. de ‘richtlijn rond incidentenbeheer’ toepassen zoals beschreven in de bijlage C van de beleidslijn ‘incidentenbeheer'

  • No labels