5. Incidentbeheer

Incident aanmelden en registreren
Incident routeren en oplossen
Incidentprocedure privacy- en beveiligingsincidenten
Definitie gebruikte termen
Onderscheid tussen de P&B-aspecten bij de behandeling van incidenten
Verantwoordelijkheid voor beoordeling en afhandeling
Datalekken
Procesgang

Het doel van de afspraken met betrekking tot het proces incidentbeheer is dat na het optreden van een incident zo snel mogelijk een herstelde dienstverlening conform de afspraken in de Suwi Keten SLA wordt gerealiseerd.

Procedure schema incidentbeheer

Afbeelding 2: Procedure schema incidentbeheer

Incident aanmelden en registreren

Gebruikers van de Suwinet-Services melden de geconstateerde incidenten en service requests in eerste instantie binnen de eigen organisatie.
Verstoringen binnen het eigen beheerdomein, zonder ketenimpact, zijn de verantwoordelijkheid van de eigen partij en vallen buiten de scope van het Ketenbreed Incidentbeheer.
Een ketenbreed incident is een verstoring waarvoor geldt dat;
de oorzaak in het beheerdomein ligt van één van de Suwi-partijen en
één of meer partijen - anders dan de veroorzakende partij – gevolgen ondervindt van deze verstoring.
Iedere partij meldt actief incidenten met ketenimpact aan de Suwidesk, inclusief eigen referentienummer.
Bij incidenten waarbij de oorzaak van het incident ligt bij de ketenpartij zelf wordt tevens een inschatting gegeven van de te verwachten oplostermijn.
De Suwidesk prioriteert een incident conform de afspraken uit de Keten SLA, registreert het incident en geeft het referentienummer van de Suwidesk aan de ‘aanmeldende’ servicedesk.
Incidenten krijgen bij registratie een prioriteit met daaraan gekoppeld een indicatieve oplostijd (zie tabel incidentbeheer /prioriteiten in de Keten SLA). Vaak zal dat het geval zijn bij incidenten over de kwaliteit van gegevens, omdat oplossing van deze incidenten vaak een langere doorlooptijd kennen.

Incident routeren en oplossen

De Suwidesk informeert de partijen via mail over storingen met behulp van verzendlijsten, die naast servicedesken ook beheerders en andere belanghebbenden kan bevatten.
De Suwidesk routeert ketenbrede incidenten binnen de vastgestelde reactietijd (zie Keten SLA) naar een oplosgroep. Hierbij wordt het referentienummer (van de Suwidesk) van het incident vermeld.
Indien nodig wordt een ketenbreed incident door een partij gerouteerd naar een leverancier van een ketenpartij. De Servicedesk van de ketenpartij blijft echter altijd verantwoordelijk voor de monitoring van de voortgang en de communicatie naar de indiener en/of Suwidesk. De Suwidesk verspreidt deze informatie vervolgens via de geëigende route aan afnemers.
Terugkoppeling van de voortgang aan de Suwidesk vindt altijd plaats onder vermelding van Suwidesk incidentnummer. Ook wordt - voor zover bekend - altijd de oorzaak van het incident teruggekoppeld.
De oplosgroep zal de Suwidesk tijdig op de hoogte brengen van een dreigende overschrijding van de oplostijden. Aanmelder en oplossende partij overleggen of de overschrijding wordt geaccepteerd of dat de escalatieprocedure wordt gestart.
De oplosgroep draagt zorg voor terugkoppeling van de voortgang aan de Suwidesk onder vermelding van het Suwidesk incidentnummer
Bij incidenten met classificatie 1 en 2 heeft de Suwidesk het recht om de toegang tot de vrijgegeven testomgeving in te trekken en deze zelf te gaan gebruiken voor de afhandelingen van één of meerdere incidenten.

Incidentprocedure privacy- en beveiligingsincidenten

Het ketenbrede incidentbeheer kent specifieke incidenten van het type privacy- en beveiligingsincident. Dit onderdeel is een richtlijn over wanneer het kenmerk ‘privacy- en beveiligingsincident’ van toepassing is op een incident en hoe de ernst van een privacy- en beveiligingsincident wordt bepaald.

Definitie gebruikte termen

Privacy: de mate waarin persoonsgegevens zijn beschermd tegen het in handen vallen van onbevoegden.
Beveiliging: omvat de volgende deelgebieden:

Beschikbaarheid: de mate waarin een faciliteit beschikbaar is op momenten dat dit voor een ketenproces is gewenst en/of is afgesproken

Integriteit: de mate waarin de werking van processen en de gegevens zonder fouten zijn

Vertrouwelijkheid: de mate waarin processen en gegevens slechts beschikbaar zijn voor diegenen die daar recht op hebben, ook wel exclusiviteit genoemd.

Onderscheid tussen de P&B-aspecten bij de behandeling van incidenten

De afhandeling van incidenten en calamiteiten die uitsluitend betrekking hebben op het aspect Beschikbaarheid, wordt verzorgd door de standaard incidentafhandelingsprocedure aanvullende eisen worden er niet gesteld.

Voorbeelden van vertrouwelijkheid-incidenten

Personen of applicaties kunnen/konden[1] toegang krijgen tot beschermde faciliteiten en/of gegevens[2] zonder dat zij daar recht op hadden, bijvoorbeeld:

Aan een persoon of applicatie is een autorisatie gegeven zonder dat hiervoor toestemming is verleend door een bevoegd persoon;
Een onbewaakte computer die niet is vergrendeld.
De toegangsmiddelen[3] (bijvoorbeeld username/password) worden (al dan niet opzettelijk) gebruikt door een andere geautoriseerde[4]
Autorisatiemechanismen worden omzeild, bijvoorbeeld:
door het niet of onvoldoende functioneren van beveiligingsmechanismen;
doordat de werkende beveiligingsmechanismen onvoldoende bescherming bieden;
vanwege een succesvolle aanval door een hacker

Voorbeelden van privacy-incidenten

Persoonsgegevens zijn of waren[5] beschikbaar voor personen voor wie deze niet zijn bedoeld, bijvoorbeeld vanwege:

het verwerken van persoonsgegevens zonder doelbinding
de zichtbaarheid voor onbevoegden van persoonsgegevens op een beeldscherm of document op een onvoldoende bewaakte[6] werkplek;
het opbergen van documenten of onbeschermde gegevensdragers met persoonsgegevens in een onvoldoend bewaakte of afgesloten kast of lade;
het opslaan van elektronische persoonsgegevens op een onvoldoend beschermd of bewaakt medium;
het afdrukken van persoonsgegevens op een onvoldoend bewaakte printer of kopieerapparaat;
het transport van documenten of onbeschermde gegevensdragers met persoonsgegevens op een onvoldoend beschermde wijze.

Verantwoordelijkheid voor beoordeling en afhandeling

Bij het beoordelen en het proces van afhandelen van beveiligingsincidenten hebben de security- en privacyfunctionarissen van de betrokken organisaties een prominente rol. En zijn verantwoordelijk voor de coördinatie en afhandeling van incidenten.

Beoordeling Ernst

De ernst van het aspect beveiliging en privacy wordt beoordeeld op basis van de onderstaande tabel.

Ernst	Omschrijving per aspect
Licht	De schending blijft binnen de hieronder omschreven criteria: Een schending van de privacy en/of de exclusiviteit was/is beperkt van omvang en kon/kan worden gecorrigeerd zonder dat de privacy van de betreffende personen hiervan schade ondervinden of hebben ondervonden[7]. Een dergelijk incident heeft, vergeleken met niet-P&B incidenten, een afwijkende afhandeling nodig, gericht op het: * zo nodig opheffen van oorzaak van de gebeurtenis; * zo nodig herstellen van de schade; * starten van een wijziging ter voorkoming van een herhaling van de gebeurtenis De laatste actie mag pas worden overgeslagen als het risico[8] van een herhaling gering is en de kosten en inspanning daarmee onevenredig hoog zijn.
Hoog	De schending blijft binnen de omschreven criteria: Een schending van de privacy en/of de exclusiviteit was/is van aanzienlijke omvang en kon/kan niet worden gecorrigeerd zonder dat de privacy van de betreffende personen hiervan schade ondervinden of hebben ondervonden of hiervoor een reëel risico lopen of liepen[9]. Een dergelijk incident heeft, vergeleken met niet-P&B incidenten, een afwijkende afhandeling nodig, gericht op het zo spoedig mogelijk: * opheffen van de oorzaak van de gebeurtenis; * zonodig informeren van de betrokkenen; * herstellen van de schade; * starten van een wijziging ter voorkoming van een herhaling van de gebeurtenis
Zeer Hoog =Calamiteit	De schending voldoet aan de volgende criteria: Een schending van de privacy en/of beveiliging was/is van omvang zodanig dat deze de bedrijfsvoering van één of meerdere Suwi-partijen raakt, het ministerie raakt, of een publieke zaak wordt. Een dergelijk incident escaleert naar de verantwoordelijke vertegenwoordiger(s) van betrokken partijen. Als is aangetoond dat de schadelijke werking van een P&B-calamiteit kan worden opgeheven door het uitschakelen van (een deel) van Suwinet, dan zal de Security Officer van het BKWI, in overleg met de betrokken Security Officers van de ketenpartijen en mogelijk met technisch deskundigen, hiertoe opdracht geven aan de Suwidesk.

Datalekken

De meldplicht datalekken geldt al sinds 2016. Onder de Europese privacywet die sinds 25 mei 2018 geldt, de Algemene verordening gegevensbescherming (AVG), blijft de meldplicht datalekken bestaan. De Autoriteit Persoonsgegevens kan hoge boetes opleggen als organisaties zich niet houden aan de AVG, waaronder het niet (tijdig) melden van datalekken.

De meldplicht en boetedreiging dwingt organisaties om naar de AP en naar de getroffen personen transparant te zijn over datalekken en om datalekken zo snel mogelijk te dichten.

Een datalek gaat altijd over persoonsgegevens en niet over (gevoelige) bedrijfsinformatie. Bij een datalek is sprake van een ‘inbreuk op de beveiliging waardoor persoonsgegevens zijn blootgesteld aan verlies of onrechtmatige verwerking’. Onder een datalek valt dus niet alleen het vrijkomen (lekken) van persoonsgegevens, maar ook vernietiging daarvan en andere vormen van onrechtmatige verwerking.

Ook een vermoeden van datalek dient gemeld te worden aan de Autoriteit Persoonsgegevens. Als het vermoeden vals alarm blijkt te zijn kan de melding weer ingetrokken worden.

Procesgang

Als er een (vermoeden van een) datalek is, wordt dit als een prio 1 incident gemeld bij de Suwidesk. Bij een vermoeden van datalek wordt het partij eigen proces gevolgd en daarnaast de Suwidesk geïnformeerd. Dit dient zowel schriftelijk (per mail aan Suwidesk@bkwi.nl) en daarnaast ook verplicht telefonisch gemeld te worden. Dit in verband met de 72 uur termijn die staat voor de melding aan de Autoriteit Persoonsgegevens.

Bij de melding aan de Suwidesk wordt in elk geval het volgende aangegeven:

of er mogelijk sprake is van een datalek
zo ja, of het een meldenswaardig datalek is
Van hoeveel personen is de data gelekt?
Welke persoonsgegevens zijn gelekt?
Wat is de oorzaak van het lek?
Is het lek onder controle?
Welke maatregelen zijn er (al) getroffen?

Verder volgt dit datalek het proces van incidentbeheer prio 1 met als enige verschil de mogelijke melding bij de Autoriteit Persoonsgegevens. Elke partij heeft zijn eigen verantwoordelijkheid bij het melden van een datalek bij de Autoriteit Persoonsgegevens. Als bij BKWI een datalek geconstateerd wordt door BKWI vindt deze melding plaats via UWV.

[1] Hiervan is dus ook sprake wanneer van de ongeautoriseerde toegang geen gebruik is gemaakt.

[2] Het betreft hier zowel gegevens die beschermd zijn door een applicatie als gegevens op een beveiligde informatiedrager.

[3] verkregen al dan niet met de medewerking van een andere geautoriseerde

[4] Dit geldt ook wanneer de overtreder dezelfde autorisatie bezit.

[5] Hiervan is sprake, wanneer van deze beschikbaarheid geen gebruik is gemaakt.

[6] De eisen aan de kwaliteit van de afsluiting, bescherming of bewaking hangt af van de gevoeligheid van de informatie; deze eisen moeten zijn vermeld in een ter plaatse geldend en bekend gemaakt document, bijvoorbeeld over documentclassificatie.

[7] Als een persoon wiens privacy het betreft een klacht heeft ingediend die verband houdt met dit incident, dan is de ernst “Hoog”.

[8] Risico is het product van de kans dat het incident zich herhaalt en de schade die daarvan het gevolg kan zijn.

[9] Als een persoon wiens privacy het betreft een klacht heeft ingediend die verband houdt met dit incident, dan is de ernst minimaal “Hoog”.