10 tips om legacy systemen te beveiligen

“Legacy” is een term die binnen IT gebruikt wordt om verouderde software of systemen aan te duiden die vaak ook niet langer ondersteund worden door de maker er van. In tijden waarin steeds nieuwe manieren worden gevonden om binnen te dringen in systemen en netwerken is dit een beveiligingsrisico: de maker zal geen aanpassingen voorzien om de software of systemen te beschermen. Uiteraard is het daarom aan te raden geen verouderde of minder beveiligde software te gebruiken om persoonsgegevens te verwerken: het gebruik van dergelijke systemen botst met het basisprincipe van vertrouwelijkheid en integriteit van persoonsgegevens zoals voorzien in de privacywetgeving, niet in het minst GDPR.

Echter, tal van mogelijke redenen maken het stopzetten van het gebruik van legacy systemen niet altijd evident: het traject voor nieuwe software loopt vertraging op, of er is geen vervanging voor de oude systemen, of het is budgettair (nog) niet mogelijk, of … Hierdoor is de realiteit dat men soms (tijdelijk) met legacy systemen zit opgezadeld.

Deze blogpost wil een aantal nuttige tips aanreiken aan DPO’s die geconfronteerd worden met legacy systemen en samen met de IT afdeling moeten kijken hoe er toch een  minimum niveau aan beveiliging kan worden geborgd.

  1. Waar mogelijk, zorg dat legacy software niet langer in contact staat met het netwerk of internet. Indien die connectie nodig is, zorg er voor dat de software draait op een computer waarbij de toegang tot het netwerk en internet sterk beperkt is: plaats het systeem in een afgescheiden deel van het netwerk, blokkeer toegang tot netwerkschijven, mail, en webbrowsers.
  2. Vermijd het gebruik van onbekende diensten zoals macro’s of browser plugins. Veel mogelijke aanvallen maken gebruik van dergelijke diensten.
  3. Vermijd het gebruik van verwijderbare media zoals USB sticks, deze kunnen namelijk onbetrouwbare inhoud bevatten.
  4. Converteer verouderde systemen naar ‘thin client’-apparaten die alleen worden gebruikt om verbinding te maken met betrouwbare systemen. Op die manier zal het verouderde systeem louter dienen als doorgeefluik naar een sterker, betrouwbaarder systeem.
  5. Verwijder onnodige diensten van verouderde servers. Louter de hoogst noodzakelijke diensten voor de continuïteit van de onderneming zouden geactiveerd mogen zijn.
  6. Verwijder de mogelijkheid tot toegang op afstand (ook wel ‘remote support’, zoals Teamviewer, VNC, e.d.m.) van verouderde systemen, servers en diensten.
  7. Overweeg om een extra ondersteuningscontract af te sluiten bij de fabrikant (zoals Microsoft dat nog een tijd voor Windows XP doet)
  8. Voorzie een uitgebreide monitoring- en antivirussoftware op het legacy systeem zodat eventuele inbreuken sneller opgemerkt worden
  9. Installeer een anti-virus toepassing om inbreuken te detecteren en hopelijk te verwijderen
  10. Stel een incident procedure op: de kans op een inbreuk met een legacy systeem is aanzienlijk groter, dus je kunt maar beter voorbereid zijn!

Mocht dit nog niet duidelijk zijn: deze tips helpen om legacy systemen op een veiligere manier actief te houden. Dit is echter per definitie tijdelijk!

Data Register GDPR: aanbeveling CBPL

De Privacycommissie heeft een aanbeveling gepubliceerd over het verwerkingsregister dat artikel 30 uit de GDPR oplegt. Het is een lijvig document waar vrij gedetailleerd de voorwaarden en context rond het verwerkingsregister worden overlopen. Het is niet de bedoeling een volledig overzicht te geven, maar een aantal interessante punten die mij opvielen:

  • Ook de verwerker moet een verwerkingsregister bijhouden ten aanzien van de verwerkingen die hij doet voor de verantwoordelijke (dit is echter een light versie, oftewel minder verplichte vermeldingen)
  • De uitzondering die geldt voor bedrijven met minder dan 250 werknemers is een wassen neus: het is niet de grootte van een onderneming die bepaalt of er meer of minder risico’s zijn voor de verwerking. De uitzondering geldt niet voor verwerkingen die “niet incidenteel” zijn, wat concreet betekent dat verwerkingen van klantengegevens of eigen personeel al aanleiding geven tot het verplicht bijhouden van het register. Ook de KMO dus! (ik vraag me af wie zich überhaupt nog kan beroepen op die uitzonderingen)
  • Concreet beveelt de Privacycommissie aan dat iedere onderneming een register bijhoudt.
  • Men kan zich baseren op de reeds eerder ingediende aangifte, het register vervangt in feite deze aangifte (dit geldt dus niet voor verwerkers, die geen aangifte moe(s)ten indienen).
  • Het register is niet bedoeld om openbaar te publiceren (dit in tegenstelling tot de aangifte), enkel in het kader van de verantwoordingsplicht die is opgenomen in de GDPR en als informatiebron voor de Privacycommissie wanneer nodig.
  • Vrijstellingen voor de huidige aangifteplicht (verwerkingen met betrekking tot klanten, leveranciers, personeel) gelden NIET voor het register
  • Er is geen vast model voor het register, zolang het schriftelijk, electronisch en begrijpelijk is (White Wire heeft hier een template voor beschikbaar gesteld: voor zowel de verantwoordelijke als de verwerker)
  • Het register hoeft niet per se in een landstaal te worden opgesteld, een Engels register voor een multinational is prima.

Tot slot bevat de aanbeveling nog een aantal annexen met toelichting, zeker nuttig om eens te bekijken!

Wat is een persoonsgegeven?

De nieuwe Europese privacy-verordening die in mei 2018 van kracht gaat (GDPR, de General Data Protection Regulation) zal zorgen voor een heuse omwenteling in de wereld van persoonsgegevensverwerking. Talloze bedrijven zullen genoodzaakt worden om hun interne processen in vraag te stellen en deze aan te passen. Inschatten hoe of wat begint met één centrale vraag: wat is een persoonsgegeven?

De Working Party 29 of WP29, een Europees adviesorgaan over gegevensbescherming, heeft in een toonaangevend advies uit 2007 geconcludeerd dat het de bedoeling van de Europese wetgever was om een brede inhoud aan het begrip persoonsgegeven te geven, maar niet zonder er grenzen aan te stellen.

Deze blogpost beoogt om het 24 pagina’s tellend advies in iets compactere vorm weer te geven waarbij we ons baseren op de vier bouwstenen die de WP29 gebruikt om te oordelen of een gegeven nu een persoonsgegeven is of niet. Deze bouwstenen vinden hun oorsprong in de definitie die ook in de GDPR behouden blijft: iedere informatie, betreffende, een geïdentificeerde of identificeerbare, natuurlijke persoon.

Iedere informatie (“any information”)

Alle informatie die terug kan worden getraceerd naar een natuurlijk persoon zal worden gedefinieerd als een persoonsgegeven. De WP29 heeft steeds bewust een brede definitie gehanteerd. Niet alleen de objectieve gegevens zoals adres, gewicht of bloedgroep worden beschermd. Ook subjectieve gegevens zoals werkcompetenties, gemoedstoestand of kredietwaardigheid vallen hier onder.

Betreffende (“relating to”)

Algemeen kan men stellen dat informatie wordt geacht een persoon te “betreffen” wanneer het om informatie over die persoon gaat. De resultaten van een medisch onderzoek van een patiënt gaan over de situatie van de patiënt.

Echter, er zijn ook situaties waar het niet altijd duidelijk is om te bepalen of informatie iemand “betreft”. Soms gaat informatie over voorwerpen en niet over personen. Maar deze voorwerpen kunnen iemands eigendom zijn, de informatie wat betreft deze voorwerpen kan dus worden gelinkt aan een persoon.

Zo kan bijvoorbeeld de waarde van een woning een persoonsgegeven zijn als deze waarde wordt gebruikt om de omvang van de belastingverplichtingen van een individu vast te stellen. Op dat moment wordt de waarde namelijk niet gezien als een objectief bedrag over een huis (het huis is zoveel waard) maar wordt het in context gekoppeld aan een persoon (persoon X is in het bezit van huis Y dat zoveel waard is en daarom is zijn belastingaanslag Z).

 Geïdentificeerd of identificeerbaar (“identified or identifiable”)

Een natuurlijke persoon kan als identificeerbaar worden beschouwd als hij binnen een groep kan worden onderscheden van de rest. Deze identificatie kan gebeuren met behulp van naam, eigenschap of uiterlijke kenmerken (art. 4, 1) GDPR).

Waar de naam de meest voor de hand liggende identificator is het ook mogelijk dat iemand identificeerbaar is met behulp van een combinatie van verschillende gegevens.

Om te bepalen of een persoon identificeerbaar is, moet men kijken naar alle middelen die redelijkerwijs door de verwerkingsverantwoordelijke kunnen worden ingezet om iemand te identificeren. Een louter hypothetische mogelijkheid tot identificatie is niet voldoende, er dient bijvoorbeeld rekening te worden gehouden met de kostprijs en de technische know-how om dit te kunnen bepalen.

Natuurlijk persoon

Principieel wordt enkel informatie over natuurlijke personen in leven geviseerd, gegevens over overleden personen of over rechtspersonen worden initieel niet beschouwd als persoonsgegevens. Echter is het wel mogelijk dat deze gegevens iets kunnen zeggen over natuurlijke personen die nog in leven zijn, denk bijvoorbeeld aan de informatie in een medisch dossier die vaak niet enkel handelt over de overledene, maar ook over familie, verpleegkundigen, artsen en dergelijke meer. Dergelijke informatie blijft een persoonsgegeven, ookal is de persoon over wie het medisch dossier gaat overleden.

 

 

GDPR data register template

De GDPR legt meer nadruk op de documentatie- en verantwoordingsplicht die geldt bij het verwerken van persoonsgegevens. Eén van de belangrijkste speerpunten daarin is het op te stellen data register (art. 30 GDPR). Er zijn op dit moment geen ‘officiële’ modellen of vormvereisten voor het data register, en we krijgen dan ook vaak de vraag van klanten “Hoe moet dat data register er nu concreet uit zien?”.

Je kunt ondertussen al vele tools vinden, vaak in een SaaS variant, die een antwoord bieden op die vraag maar de meeste van die tools zijn toch vooral bedoeld voor grotere organisaties met complexe verwerkingsactiviteiten die ook effectief een tool nodig hebben om al die informatie beheersbaar te houden.

Er is echter ook een groot segment aan organisaties waar een dergelijke tool overkill is (niet in het minst uit budgetair oogpunt), denk bijvoorbeeld aan KMO’s, de eerstelijns zorgsector, of VZWs. Om hierin te voorzien deelt White Wire graag 2 templates (een versie Word en een versie Excel) die zijn opgesteld en die gebruikt kunnen worden als data register: beiden bevatten de wettelijke verplichtingen uit de GDPR met een paar kleine toevoegingen die nuttig leken.

Hopelijk helpen ze een aantal organisaties vooruit en bieden ze een antwoord op die eerste vraag: “Hoe ziet zo’n dataregister er dan uit?”. Niet lang daarna zal echter een tweede vraag opdoemen: “Nu weet ik hoe het er uit ziet, maar hoe definieer ik nu juist een verwerkingsactiviteit?”. Een zeer terechte vraag, maar één die vaak organisatie-, of toch zeker sector-, specifiek is en die White Wire graag helpt beantwoorden.

Link naar template pagina

Voorbeeld: een retail organisatie heeft als hoofdactiviteit goederen verkopen en verwerkt hiervoor persoonsgegevens. Een mogelijke verwerkingsactiviteit is dan “Klanten- en orderbeheer”. Voor die activiteit worden 2 soorten gegevens verzameld: de gegevens die noodzakelijk zijn voor de levering van een goed (naam, adres, …) en gegevens over de aankopen en voorkeuren (b.v. profiling via de website of op basis van aankoopgedrag). De wettelijke basissen zijn dan voor de eerste set gegevens “noodzakelijk voor de uitvoering van een overeenkomst met betrokkene” en de tweede set “na het verkrijgen van toestemming van betrokkene.”

DPIA: wanneer voorafgaande raadpleging?

Na de Privacycommissie eerder dit jaar heeft nu ook de Working Party 29 een advies gepubliceerd rond de uitvoering van een Data Protection Impact Assessment (DPIA)

Link CBPL: https://www.privacycommission.be/nl/node/19686

Link WP29: http://ec.europa.eu/newsroom/document.cfm?doc_id=44137

Naast richtlijnen rond de vraag “Wanneer een DPIA uit te voeren?” was een andere belangrijke vraag die beide publicaties beantwoorden “Wanneer moet men op voorafgaande consultatie bij de Data Protection Autority (DPA)?”, welke in Belgie dus de Privacycommissie is.

De voorafgaande consultatie is het overleg dat plaats moeten vinden indien de verwerkingen waarop men een DPIA uitvoert resulteren in een hoog risico voor individuen wiens gegevens verwerkt worden. De GDPR zelf is onduidelijk wanneer dit juist zou moeten aangezien het betreffende artikel (36) en de overweging die er bij hoort (84) elkaar lijken tegen te spreken.

Er zijn twee mogelijk opties:

  • Raadpleging na de uitvoering van een DPIA wanneer er een hoog risico blijkt en men nog niet heeft bepaald welke maatregelen moeten worden genomen om dit risico te beperken (ook wel inherente risico’s)
  • Raadpleging na de uitvoering van een DPIA wanneer er een hoog risico blijkt, zelfs nadat men maatregelen heeft genomen om het risico te beperken (ook wel het residuele risico)

Beide adviezen kiezen hierin nu een duidelijk standpunt: raadpleging van de DPA moet enkel plaats vinden als er een hoog residueel risico is, met andere woorden als er dus ondanks maatregelen toch nog altijd een hoog risico blijft bestaan. Indien dit het geval is zal men de DPA raadplegen en afstemmen welke maatregelen nodig zijn om tot een aanvaardbaar risico te komen.