Aanscherping van ISO 27001 en ISO 27002

Mijn grootste probleem met de ISO 27001 is dat het aan de ene kant onvoldoende de vinger op de zere plek legt wat betreft de kern van informatiebeveiliging en aan de andere kant, naar mijn idee in de hoop volledig te zijn, overbodige zaken bevat die juist alleen maar afleiden van die kern.

De kern van informatiebeveiliging is, zoals eerder vermeld, risicomanagement. Wat daarvoor nodig is, het vaststellen van de organisatiedoelen en de processen die daar invulling aan geven, komt niet aan bod in ISO 27001. In hoofdstuk 4 wordt gesproken over doelen, maar daarbij gaat het vooral over het doel van informatiebeveiliging, niet het doel van de organisatie. Hoofdstuk 4 is het eerste inhoudelijke hoofdstuk van ISO 27001. Ik verwacht daar de kern van informatiebeveiliging in te lezen. Ik lees daar vooral hoe informatiebeveiliging als doel wordt neergezet en niet als middel, om met behulp van betrouwbare informatie, organisatiedoelen te behalen.

Een ander belangrijk onderwerp bij het inrichten van informatiebeveiliging is verantwoordelijkheid. Zonder dat kom je nergens. Dit onderwerp wordt in hoofdstuk 5 ingevuld. Hoewel ik vind dat wat er staat niet verkeerd is, kan het scherper en met name wat betreft de verantwoordelijkheid van het lijnmanagement. Bij een grote organisatie heeft de directie bepaalde taken en verantwoordelijkheden gedelegeerd naar het lijnmanagement. Een lijnmanager heeft vaak de verantwoordelijkheid voor een bepaalde afdeling. Binnen zo'n afdeling vindt een hoop verwerking van informatie plaats. Omdat dat de plek is waar de verwerking plaatsvindt, is ook dat de plek waar de risicobeheersing rondom die verwerking hoort te gebeuren. Risicomanagement is in een grote organisatie dus meer een taak voor het lijnmanagement, dan voor de directie. De directie moet in dat geval vooral sturend en faciliterend bezig zijn. Sturend als in verantwoordelijkheden beleggen en met lijnmanagement over dit onderwerp in gesprek gaan en faciliterend als in het beschikbaar stellen van middelen, tijd, geld en kennis zodat lijnmanagement invulling kan geven aan haar verantwoordelijkheid. Ja, dit kan je ook lezen in 7.1, maar bekijk die tekst eens goed. Ook mijn insteek kan uitgebreider, maar het is in ieder geval meer richtinggevend dat die vage, algemene 7.1 tekst.

Maar de verantwoordelijkheid voor lijnmanagement staat toch in hoofdstuk 5.3? Ja en nee. Ja, je kan het er uithalen als je dat wil en nee, het staat er dus niet expliciet. In een grote organisatie kan je er niet omheen om lijnmanagement onderdeel te maken van je aanpak voor informatiebeveiliging. Toch zie ik in teveel organisaties dat lijnmanagement daar onvoldoende bij betrokken is en ik druk me daarmee nog zachtjes uit. Hoe lijnmanagement betrokken moet worden bij informatiebeveiliging zou ik heel graag expliciet in de ISO 27001 terug zien, zodat een organisatie er bij de inrichting van informatiebeveiliging niet omheen kan.

De overbodige zaken zie ik vooral in hoofdstuk 4 en 7. Als je je organisatiedoelen, bijbehorende processen en verantwoordelijkheden helder hebt, wat voegt hoofdstuk 4 dan nog toe? Tegen diegene die zeggen dat hoofdstuk 4 juist bedoeld is voor die doelen zeg ik ‘nee’. Het gaat om het behalen van organisatiedoelen, waarbij informatiebeveiliging een middel is. Hoofdstuk 4 maakt van informatiebeveiliging een doel op zich. Dat is niet juist.

Wat betreft hoofdstuk 7, laten we die puntsgewijs afgaan. 7.1 is vaag en algemeen. Als je met informatiebeveiliging aan de slag gaat en je daar goed over laat adviseren, dan kom je er vanzelf achter wat daarvoor nodig is. Dit vooraf als eis stellen is nikszeggend en overbodig. Het idee achter 7.2 is oke, maar zo werkt de praktijk niet. Organisaties moeten informatiebeveiligingsspecialisten in dienst nemen en hun advies serieus nemen. Verwachten dat alle personen ‘die onder haar gezag werkzaamheden verrichten’ de juiste competentie hebben is niet realistisch. Vervang 7.2 dus door ‘neem een CISO in dienst en luister daar naar’. Over 7.3, willen alle managers die ooit het informatiebeveiligingsbeleid van hun organisatie hebben gelezen hun hand opsteken? Precies. Leuk hoor, bewustzijn. Je vraag dus van mensen die hun primaire aandacht bij heel iets anders hebben, om zelf aan informatiebeveiliging te denken. Laat de huidige praktijk vooral uitwijzen hoe realistisch dat is. Verlang niet dat managers jouw wereldje van informatiebeveiliging binnenstappen. Stap hun wereldje in en voeg informatiebeveiliging toe aan hun werkwijze. Organisaties werken vaak via projecten. Maak informatiebeveiliging daar onderdeel van. Regel via de directie dat informatiebeveiliging een verplicht onderdeel wordt van projectaanpakken en change management en dat managers de CISO serieus nemen als deze langskomt om bijvoorbeeld geconstateerde kwetsbaarheden te bespreken. Als laatste 7.4. Dat is werkelijk zo algemeen en dus nikszeggend, niets wat daar staat helpt zowel informatiebeveiliging als de communicatie daarover. Echter, bij een audit ben ik wel verplicht daar wel iets zinnigs over zeggen. Communicatie is daarmee een doel geworden. Bij een kleine organisatie zal communicatie eenvoudig zijn. Een grote organisatie heeft vaak een communicatie-afdeling. In beide gevallen voegt dit punt niets toe.

ISO 27002

Mijn grootste probleem met ISO 27002 is dat de norm niet is aangepast op de komst van ISO 27001. Om dat goed uit te leggen, even wat achtergrond over ISO 27002.

Met wat nu ISO 27002 is, is het allemaal begonnen. Toen informatiebeveiliging nog in de kinderschoenen stond, bedacht Shell in Engeland regels om dat op orde te brengen. In plaats van dat voor zichzelf te houden, maakten ze die beschikbaar voor anderen, wat in 1995 geleid heeft tot BS 7799, de Code voor informatiebeveiliging. Dat omvatte toen, heel logisch, de verschillende facetten van informatiebeveiliging, zowel organisatorisch als technisch. Een paar jaar later is een norm verschenen die het organisatorische deel beter en uitgebreider behandelde (wat nu ISO 27001 is), waardoor er naar mijn idee geen reden meer is om dat nog steeds in ISO 27002 te benoemen. Echter, dat is er wel ingebleven.

Volgens bijlage A van ISO 27001 moeten de ISO 27002 maatregelen gebruikt worden in context met 6.1.3, wat gaat over de behandeling van risico’s. Dat betekent dus dat de maatregelen bij 6.1.3 gebruikt moeten kunnen worden om risico’s te mitigeren die de beschikbaarheid, integriteit of vertrouwelijkheid van informatie kunnen aantasten. Een hoop maatregelen doen dat niet concreet.

Zo gaan 5.1, 5.4, 5.8 en 5.9 meer over de organisatie van informatiebeveiliging en horen dus in ISO 27001 thuis. 5.12 is meer onderdeel van informatiemanagement. 5.5 en 5.6 zijn meer overwegingen dan maatregelen. Intellectuele eigendomsrechten uit 5.32 hebben niets met informatiebeveiliging te maken, dus weg ermee. 8.12 en 5.33 zijn zo algemeen, waardoor ze nikszeggend zijn. Ook weg ermee. 5.34 gaat over privacy. Informatiebeveiliging is onderdeel van gegevensbescherming, maar gegevensbescherming is geen onderdeel van informatiebeveiliging, dus dit punt kan er ook uit. 8.34 gaat over audits en heeft dus niet direct met informatieveiligheid te maken. De toegang tot informatie tijdens audits regel je via logische toegangsbeheer, dus waarom een aparte maatregel? Weg ermee.

Door de maatregelen 5.39, 5.40 en 5.41 in de zorg specifieke versie van ISO 27002, de NEN 7510-2, moeten informatiebeveiligers zich opeens ook bezig gaan houden met de correctheid van patiëntgegevens en medische gegevens. Volslagen idioot. Weg ermee. Aangescherpte invulling

Klagen is lekker makkelijk, dus hoe zie ik het dan wel voor me?

In ISO 27001 zie ik dus liever een aangescherpte invulling van risicomanagement. Ik heb nooit goed begrepen waarom ISO 27005 nodig is. Die inhoud moet onderdeel zijn van ISO 27001. Om risico’s goed te kunnen beheersen, is een fatsoenlijke registratie noodzakelijk. Financieel beheer en personeelsbeheer kunnen immers ook niet zonder een fatsoenlijke registratie. Ik vind het daarom opmerkelijk dat in ISO 27001 nergens gesproken wordt over de registratie van risico’s. Ik heb genoeg organisaties gesproken die beweren aan risicomanagement te doen, maar geen fatsoenlijke registratie van risico’s hebben. En, nee, geklieder in Excel geldt voor mij niet als een fatsoenlijke risicoregistratie.

ISO 27002 moet zuiver ingevuld worden met maatregelen die concreet gericht zijn om de bescherming van de beschikbaarheid, integriteit en vertrouwelijkheid van informatie. Die maatregelen moeten gehanteerd kunnen worden om de risico’s die tijdens een risicoanalyse in kaart zijn gebracht, te kunnen mitigeren. Iets anders zou daar wat mij betreft niet in thuis horen.

Daarnaast zou het goed zijn om norm, of ander soortig document, te hebben die dieper ingaat om het fenomeen risico en de analyse daarvan. Bowtie zou wat mij betreft verplicht moeten worden voor de beschrijving van een risico. Ik heb genoeg risicobeschrijvingen gezien die niet verder komen dan de oorzaak van een risicogebeurtenis, waarbij die daadwerkelijke aantasting van de beschikbaarheid, integriteit of vertrouwelijkheid van informatie, dus niet benoemd wordt. Hoewel risicoanalyse geen rocket science is, is het toch iets wat je een (paar) keer gezien en/of gedaan moet hebben om het goed te kunnen. Een goede beschrijving van dat proces zou ook geen overbodige luxe zijn voor in zo’n extra document. Ik heb mensen horen zeggen dat de invulling van de risicoanalyse juist open is gelaten, zodat organisaties dat vrij kunnen invullen. Naar mijn idee zijn er niet zo heel veel manieren om een risicoanalyse op een goede manier te doen, dus dat vind ik geen goed argument. Het open laten zorgt er alleen maar voor dat organisaties het niet goed of niet volledig doen, wat uiteraard een goede informatiebeveiliging niet ten goed komt.