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.3.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;
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 paragraafhttps://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.1.-Registratie-en-categorisatie-van-het-incident.
Bepalen van de impact
Dit is besproken in paragraafhttps://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.2.-Prioriteit-bepalen-van-een-incident.
Bepalen van de urgentie
Dit is besproken in paragraafhttps://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.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 paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.1.-Registratie-en-categorisatie-van-het-incident en paragraaf hoofdstuk https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.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.3.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 subparagraaf ‘Communicatie' in paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.3.-Behandelen-van-het-incident
Inperken van de gevolgen van het incident
Dit is besproken in subparagraaf ‘Beperken van de schade’ in paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.3.-Behandelen-van-het-incident
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 pagina 4.4. Minimale maatregelen - Beheer van wijzigingen). Voor meer detail zie paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.3.-Behandelen-van-het-incident .
Rapporteren van het incident
Dit is besproken in subparagraaf ‘Rapportering en evaluatie’ in paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.3.-Behandelen-van-het-incident .
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 subparagraaf ‘Rapportering en evaluatie’ in paragraaf https://vlaamseoverheid.atlassian.net/wiki/spaces/ICRDEV/pages/6423447746/4.5.3.+Aanvullende+informatie+over+de+maatregelen+incidentbeheer#4.5.3.3.3.-Behandelen-van-het-incident
4.5.2.1. Minimale algemene maatregelen
IC klasse | Minimale maatregelen |
---|---|
Klasse 1 en Klasse 2 kennen dezelfde maatregelen:
| |
Alle maatregelen van Klasse 1 / Klasse 2 +
| |
Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +
| |
Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +
|
Integriteit
IC klasse | Minimale maatregelen |
---|---|
Klasse 1 en Klasse 2 kennen dezelfde maatregelen:
| |
Alle maatregelen van Klasse 1 / Klasse 2 +
| |
Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +
| |
Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +
|
Beschikbaarheid
IC klasse | Minimale maatregelen |
---|---|
Klasse 1 en Klasse 2 kennen dezelfde maatregelen:
| |
Klasse 3, Klasse 4 en Klasse 5 kennen dezelfde maatregelen: Alle maatregelen van Klasse 1 / Klasse 2 +
|
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:
| |
Alle maatregelen van Klasse 1 / Klasse 2 +
| |
Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 +
| |
Alle maatregelen van Klasse 1 / Klasse 2 + Klasse 3 + Klasse 4 +
|
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:
|