Hoe snel moet je van de wet een nieuwe securitystandaard implementeren?

norm-security-beveiliging-certified-gecertificeerdEen lezer vroeg me:

In de ICT zijn de beveiligingseisen volop in beweging. Het is dus welhaast onmogelijk om deze allemaal stipt na te volgen, zeker bij grote pakketten waar het doorvoeren van wijzigingen vele maanden (zo niet jaren) kan kosten vanwege complexiteit en testen en evaluatie. Is er juridisch gezien een termijn waarbinnen nieuwe standaarden geïmplementeerd moeten zijn?

Dit is een persoonlijke frustratie van mij, maar de wet kent eigenlijk überhaupt geen eis dat je enige security-standaard moet volgen, of zelfs maar dat je product enige security moet hebben. Fysieke veiligheid wel (productveiligheid, art. 6:186 BW) maar je informatiebeveiliging mag volstrekt brak zijn. Ik weet niet waarom.

De enige echte uitzondering is die van systemen die persoonsgegevens verwerken. Daar bepaalt de Wet bescherming persoonsgegevens (art. 13 Wbp) dat je “passende technische en organisatorische maatregelen” moet nemen “om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking.”

De in 2013 geformuleerde beleidsregels Beveiliging van persoonsgegevens van de Autoriteit Persoonsgegevens adviseren te handelen binnen een plan­do­check­act­cyclus: beoordeel de risico’s, gebruik erkende beveiligingsstandaarden en controleer en evalueer de resultaten. Er wordt wel naar standaarden verwezen, maar dat laat meteen zien waarom dat niet werkt: het document is uit februari 2013 en de daarin genoemde norm ISO 27002:2007 werd in oktober 2013 ingetrokken.

Uiteindelijk zal het altijd neerkomen op een evaluatie achteraf als het mis blijkt te zijn gegaan. Had dit redelijkerwijs voorkomen kunnen worden met wat voorhanden was, was het redelijkerwijs te verwachten dat deze standaard gevolgd zou worden en hadden we al redelijkerwijs mogen verwachten dat er zou worden geupgrade of was dat gezien de kosten nog niet redelijk? (Met excuses aan de vraagsteller die me nadrukkelijk vroeg de term ‘redelijk’ te vermijden maar dat is ben ik bang een MUST in de zin van RFC 2119.)

Arnoud

13 reacties

  1. Uiteindelijk zal het altijd neerkomen op een evaluatie achteraf als het mis blijkt te zijn gegaan.
    Dit is eigenlijk totaal onacceptabel voor de rechtszekerheid van iedereen die het betreft. Ik stel voor dat alle beheerders van websites die persoonsgegevens beheren (alle webshops) jaarlijks een verzoek doen bij de Autoriteit Persoonsgegevens (of een andere vertegenwoordiger van de staat) om binnen redelijke termijn te laten beoordelen of hun website op dat moment aan de gestelde eisen voldoet. Als er een probleem is en de Autoriteit Persoonsgegevens geen gehoor heeft gegeven aan het verzoek, dient rechtsvervolging gestaakt te worden.

      1. Keuringsdienst van waren, stoomwezen, AFM, of hoe ze tegenwoordig ook heten, en zo gaat het rijtje nog een stukje door, allemaal toezichtinstanties die namens de overheid pro-actief kijken of jij je zaakjes wel op orde hebt.

    1. Het is op andere gebieden gebruikelijk dat de eigenaar/beheerder regelmatig (op eigen kosten) veiligheidsaspecten laat controleren. Bijvoorbeeld of er geen scheurtjes in de ketels en pijpen van een chemische installatie zitten.

      Eigenlijk zou de eigenaar van zo’n website een gespecialiseerd bedrijf moeten inschakelen om een beveiligingsscan te doen, zo vaak als nodig. (Na een grote code-wijziging bijvoorbeeld.)

      1. Ik zie een heel nieuwe branche ontstaan hier. Als via wetgeving een ‘certificering’ ontstaat ben je voorlopig van werk voorzien om alle standaard WP websites en Magento webshops te ‘certificeren’.

    2. Ja, goed idee, laten we nog meer keuringsinstanties in het leven roepen met verplichte keuringen, formulieren en administraties. Alsof een ondernemer niet al voldoende te doen heeft.

      Natuurlijk moet een ondernemer zijn zaken goed op orde hebben. Zodra je het over medische gegevens hebt dan kan ik me voorstellen dat er vooraf gecontroleerd gaat worden maar voor een webwinkel die de gegevens bijhoudt die al decenia lang gewoon in een telefoonboek staan moeten we niet al te moeilijk gaan doen.

      Ik ben heel privacy bewust maar mijn NAW gegevens en BSN liggen (dankzij de overheid) toch al op straat omdat ik verplicht ben dat op mijn website te zetten. Echt heel spannend is het niet als dat óók nog via een webwinkel gelekt gaat worden.

      1. maar voor een webwinkel die de gegevens bijhoudt die al decenia lang gewoon in een telefoonboek staan

        Dat is onjuist. In het telefoonboek staan niet je laatste aankopen erbij vermeld.

        Ik ben heel privacy bewust maar mijn NAW gegevens en BSN liggen (dankzij de overheid) toch al op straat omdat ik verplicht ben dat op mijn website te zetten. Echt heel spannend is het niet als dat óók nog via een webwinkel gelekt gaat worden.

        Prima dat jij dat vindt, maar dat heeft natuurlijk niets te maken met wat voor beleid er landelijk gevoerd moet worden. Misschien hebben anderen daar wel een heel andere mening over.

    3. Typisch ‘Amerikaanse’ reactie: laat het door een officieel gecertificeerde instantie/persoon controleren, en dan zit je goed. Met gezond verstand kom je ook ver hoor!

      Los van het feit of de door jou genoemde instantie wel de mankracht heeft om dit te doen (alleen aan .nl-domeinen overschrijden we al de 5,5 miljoen; nu zullen deze niet alle beveiligd hoeven te zijn, maar zelfs als het 1% zou zijn moeten er nog 55.000 sites nagelopen worden, ieder jaar weer) moet je maar hopen dat de keuringsinstantie niet te ver achter de feiten aanholt; ICT verandert snel, dus om bij te blijven moet de keuringsinstantie ook continue bijgeschoold worden/blijven. Ook denk ik dat het een schijnzekerheid is om te denken dat 1x controle per jaar voldoende is. Door de snelle veranderingen in het beveiligingslandschap zou dat denk ik vaker moeten. Het voelt namelijk nogal verkeerd dat wanneer je wordt aangesproken op het feit dat bij jouw site gestolen gegevens gebruikt worden voor identiteitsfraude je een certificaat op tafel kunt leggen en zeggen ‘Ja, maar instantie XYZ heeft ons gecontroleerd en goedgekeurd, dus zijn wij niet aansprakelijk voor enige schade.’. En dat terwijl er een paar maanden na de controle van jouw site een groot gapend gat in de door jou gebruikte beveiliging wordt ontdekt (denk Heartbleed). Daarnaast denk ik dat je, net als in andere rechtsgebieden, ook bij de beveiliging van jouw site uit kunt gaan van een stukje eigen verantwoordelijkheid. Dat kun je bijvoorbeeld ‘afkopen’ door de inrichting en controle uit te besteden aan een derde gespecialiseerde partij, maar het blijft jouw verantwoordelijkheid.

      Net even nagezocht, maar begin 2014 bevatte het .nl-domein al 60.000 webshops. Je hebt daarnaast natuurlijk nog allerhande andere sites waar persoonsgegevens verwerkt worden; daarmee wordt het jaarlijks laten controleren van al die sites een behoorlijke onderneming.

      1. Dat is het mooie van ICT. Dat kun je voor een groot deel automatiseren. Voor een paar duizend euro kun je elke week een scan laten lopen die de meeste bekende zaken (heartbleed bv) direct signaleert. Dan zit je er redelijk kort op. Elk jaar en bij elke aanpassing een pentest en je bent redelijk veilig. Of dat betaalbaar is voor elke webshop is weer een andere uitdaging. Voorlopig gaat het nog te vaak op de basics mis https://www.owasp.org/index.php/Category:OWASPTopTen_Project

        1. Scans zijn echt niet voldoende om de serieuze beveiligingslekken te vinden, en sterker nog, ze kunnen averechts werken – sitebeheerders voeren dit soort scans doorgaans als een soort ‘keurmerk dat het veilig is’, wat dus onjuist is. Zo creeer je een onterecht gevoel van veiligheid, en een excuus voor beheerders om niet verder te gaan dan zo’n scan.

          Het vinden van beveiligingslekken is nu juist iets dat je met de huidige technologie (van applicaties, niet van de scanners) niet niet kunt automatiseren. De reden waarom is een lang betoog, maar het komt neer op het feit dat zowel de meeste programmeertalen als hardware niet ontworpen zijn om “correctheid” aan te kunnen tonen, en je dus nooit een “uitputtend” oordeel kunt vellen over de veiligheid van een applicatie of systeem.

  2. daarin genoemde norm ISO 27002:2007 werd in oktober 2013 ingetrokken

    Is het juridisch een probleem als de uitgever van een norm een versie intrekt ?

    Ik zou denken dat de norm juridisch gewoon blijft gelden en dat je minstens moet doen wat in de norm staat. Misschien is intrekken zelfs een indicatie dat je meer moet doen (als de reden van intrekken was dat de norm tekortkomingen had die in een nieuwere versie zijn opgelost); maar dat laatste lijkt me eigenlijk weer iets te ver gaan, want versies kunnen elkaar ook tegenspreken (en je wilt partijen niet verplichten telkens een nieuwe norm te laten kopen).

  3. Daar waar het de verwerking van persoonsgegevens betreft, is de beveiliging wettelijk geregeld. Nu in nationale wetgeving (Wbp) en straks in Europese wetgeving (Avg). Daar waar het niet-persoonsgegevens betreft is dat niet zo wettelijk geregeld. Dat is niet onlogisch. De verwerking van persoonsgegevens heeft namelijk impact op de persoonlijke levenssfeer van betrokkenen. Deze privacy vereist in de grondwet opgenomen bescherming. Je hebt een grondrecht op privacybescherming, maar niet op informatiebeveiliging. Persoonsgegevens zijn dus per definitie waarde- en risicovol. De grootte ervan is slechts nog afhankelijk van de aard en omvang van de specifieke persoonsgegevens.

    Bij niet-persoonsgegevens is de waarde en is het risico volledig aan de (samenwerkende) organisatie zelf ter beoordeling. Als ook de mate waarin zij zich daar tegen willen beschermen en de kosten daarvoor willen dragen. En dat doen individuele organisaties, sectoren en branches ook. Ondermeer door specifieke maatregelen/commitment/certificering af te dwingen. De NEN7510 in de zorgsector is daar een voorbeeld van. Daar waar ze dit aan elkaar vereisen valt dit wettelijk overigens wel onder de prestatieplicht van de opdrachtnemer.

    Terug naar de verwerking van persoonsgegevens, waarvan al wel heel snel sprake is overigens. Daar is het zeker geen kwestie van ‘evaluatie achteraf als het mis blijkt te zijn gegaan’. Hoe je het doet moet jezelf bepalen (lees: daarvoor moet je zelf in expertise en competentie investeren en zeker niet naar de Autoriteit Persoonsgegevens kijken) als je maar zorgt voor een passend veiligheidsniveau dat je CONTINU kunt garanderen. De kern van deze wettelijke beveiligingsplicht is juist dat er preventief wordt gehandeld om ervoor te zorgen dat het niveau passend BLIJFT (en überhaupt herkend wordt dat er iets ‘mis’ gaat). Het handelen in het kader van ‘achteraf vaststellen als het mis blijkt te zijn gegaan’ valt onder de meldplicht datalekken. Beide plichten worden op straffe van forse boetes opgelegd aan verwerkers van persoonsgegevens. In de a.s. Europese privacywetgeving is aan deze beveiligings- en meldplicht meer invulling gegeven, maar duikt ook de nieuwe plicht ‘privacy by design’ op dat zijn bijdrage levert aan de (initiële) realisatie van het passende veiligheidsniveau. In mei 2018 moet aan deze Avg wettelijk voldaan worden. Waarschijnlijk kunnen certificeringen hieraan inderdaad een bijdrage leveren, maar key is het respect voor het grondrecht dat privacy heet. Ook met certificering kun je er een potje van maken. En er is geen enkele certificering denkbaar die datalekken 100% zal kunnen uitsluiten.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.