Beheer

Security

Invoering ISO 27001: sprong in ‘t diepe

19 september 2014

Er gaat geen dag voorbij of ergens worden wel data gestolen, een website gehackt of een nieuw horrorverhaal gepubliceerd over spyware, phishing, ransomware en andere malware. Werken al die investeringen in virusscanners, IDS/IPS- systemen, firewalls en aanverwanten dan niet?

Toch wel, maar het is duidelijk dat technologie alleen het probleem van informatiebeveiliging niet kan oplossen. De lijsten met de meest voorkomende oorzaken rond beveiligingslekken, zoals de OWASP Top 10, laten een terugkerend patroon zien. Het lijkt alsof de industrie niet leert van haar fouten. Overheden worden bovendien steeds zenuwachtiger als er weer eens privacygevoelige informatie te grabbel wordt gegooid door een beveiligingslek of wanneer bedrijven weinig gevoel tonen voor de privacy van hun klanten of gebruikers.

De komende jaren worden echter een mijlpaal voor databescherming. De Europese Data Protection Legislation wordt naar alle waarschijnlijkheid in 2015 een feit en overheden zullen die dienen te vertalen naar hun eigen wetgeving. Organisaties zullen in de toekomst verantwoording moeten afleggen voor de data die ze verzamelen, en voor wat ze ermee doen.

Wordt een ISO/IEC 27001-certificaat dan binnenkort een verplichting voor bedrijven en openbare instellingen? Waarschijnlijk niet, maar het kan anderzijds een commerciële vereiste worden. Openbare aanbestedingen verwijzen meer en meer expliciet naar een ISO/IEC 27001- certificatie voor IT-diensten. En de ontboezemingen van Edward Snowden in 2013 zorgen ervoor dat informatiebeveiliging steeds belangrijker wordt. Bedrijven zoeken naar een garantie dat data veilig en betrouwbaar worden opgeslagen en behandeld door partners en leveranciers. Het is dan ook niet verwonderlijk dat de vraag naar certificatie meestal niet uit de automatiseringshoek komt. De hamvraag is: ervaart het bedrijf informatiebeveiliging als een strategisch gegeven en wil men er structureel iets aan doen, of wenst men gewoon een kader aan de muur om contracten te kunnen sluiten?

Geen IT-project

Laten we beginnen met een open deur in te trappen: ISO/IEC 27001 is geen IT-project. Wie de standaard koopt en leest, zal snel merken dat het over meer dan enkel technische maatregelen gaat. Organisaties die denken dat de IT-manager wel even snel een ISO/IEC 27001-certificatie kan ritselen, vergissen zich.

Om dit te begrijpen, volstaat het om het document te lezen. Dat telt slechts 23 pagina’s en bestaat uit twee delen: de standaard zelf en Annex A, die controles aanreikt rond informatiebeveiliging. De Annex is het meest pragmatische van de standaard en is het deel waar organisaties zich op verkijken, overtuigd als zij zijn dat voldoen aan de Annex genoeg is voor certificatie. Een dik boek met uitgebreide regels is echter nog onvoldoende; meer nog, de Annex hoeft zelfs niet gevolgd te worden. Bedrijven die andere beheersystemen gebruiken zoals COBIT of ITIL kunnen dit perfect toepassen als controlemechanisme binnen ISO/IEC 27001. Met andere woorden, de kern van de standaard is niet de Annex, maar de clausules die eraan voorafgaan.

Auditors houden hier uiteraard rekening mee en zullen eerst en vooral kijken naar Clausule 4 tot en met 10 van het eerste deel van de standaard. Die zijn verplichte kost en kunnen niet genegeerd worden. Doet een organisatie daar niets mee, dan kan ze ook niet gecertificeerd worden. De invulling van die clausules vormt het Information Security Management System (ISMS) dat uiteindelijk het proces moet vormen waarmee het management richting geeft aan zijn beveiligingsbeleid, waarmee het meet in welke mate de doelstellingen gehaald worden en bijstuurt wanneer zaken intern en extern veranderen.

Die clausules zijn allesbehalve technisch en richten zich vooral op de organisatie. De volgende vragen kunnen moeilijk beantwoord worden door de IT-manager: Wie zijn we? Wie zijn de belanghebbenden? Wat willen we beschermen? Hoe gaan we dit organiseren? Welke rollen en verantwoordelijkheden zijn er? Welke risico’s zijn er? Hoe reduceren we die risico’s tot een aanvaardbaar niveau? Wat is een aanvaardbaar niveau? Hoe gaan we dit meten? Daarom spreekt de standaard ook over leiderschap en topmanagement en zal de auditor zoeken naar het bewijs dat het proces gedragen wordt door het hele management en de organisatie.

Anders gezegd, bedrijven waar de salesmanager het initiatief neemt en vervolgens de hete ISO-aardappel doorschuift naar de IT-manager of de security officer zullen verrast opkijken bij de audit.

In het diepe

Organisaties die een succesvolle ISO/IEC 27001-certificatie nastreven, moeten het project op het juiste niveau borgen. Het heeft de ondersteuning en opvolging nodig van het management en kan enkel tot een succes leiden als iedereen overtuigd is van het nut en de doelstellingen. Het is daarom ook geen overbodige luxe om externe hulp te zoeken bij het opzetten van het ISMS en de invulling van de verplichtingen van de standaard. Niet alleen weten consultants wat ze moeten opbouwen, ze weten ook hoe ze dit moeten verkopen binnen de organisatie, het managementteam incluis.

De invoering van ISO/IEC 27001 is voor veel IT-organisaties een sprong in het diepe en druist soms in tegen het dynamische karakter van de sector. Ongetwijfeld zullen sommigen dit als nodeloze bureaucratie zien en een vertragende factor bij innovatie en productontwikkeling. Hebben diezelfde criticasters dan een antwoord op de kosten en risico’s die beveiligingsproblemen met zich meebrengen? Of is het debacle rond DigiNotar al vergeten? Of meer recent, de problemen met Heartbleed, die geleid hebben tot honderden upgrades en patches om allerhande apparatuur en software veilig te stellen?

Haalbaar

ISO/IEC 27001 garandeert niet dat informatie perfect beveiligd wordt, dat is het doel niet van de norm. Het zorgt voor een proces binnen de organisatie dat informatiebeveiliging op ieders radar plaatst door risico-analyses, bewustwording, rapportering, metingen en een voortdurend verbeteringstraject.

Eenvoudig is dit niet en het vergt een voortdurende inspanning van alle betrokken partijen. Een ISO-certificering is immers geen eenmalige oefening. Elk jaar is er een tussentijdse audit en om de drie jaar zal het certificaat opnieuw verdiend moeten worden. Voor de meeste bedrijven en organisaties is een certificaat haalbaar; het behouden is de echte uitdaging. Dat de lat hierbij steeds hoger komt te liggen is een logisch gevolg; auditors zullen immers steeds kritischer op zoek gaan naar verbeteringen in de organisatie.

Het meest gehoorde punt van kritiek rond deze ISO-norm is dat het de informatiebeveiliging an sich niet verbetert en dat gecertificeerde bedrijven nog steeds gehackt kunnen worden. So what’s the point? Individuele incidenten mogen niet worden uitvergroot en gepromoveerd tot regel. Organisaties die de norm ter harte nemen vinden er middelen in om dit soort incidenten goed te analyseren en er de lessen uit te leren die nodig zijn om zich te verbeteren in de toekomst. Het is daarbij uitermate handig om leentjebuur te spelen bij aanverwante managementsystemen, zoals de kwaliteitszorg. Root Cause Analysis, die bijvoorbeeld gebruik maakt van de 5-whys-methodologie (zie kader), is zeer efficiënt in de analyse van beveiligingsincidenten en zal dikwijls de vinger op de zere plek leggen. Dat de echte reden dan zelden nog iets te maken heeft met technisch falen, maar eerder met ondoordachte beslissingen of ontbrekende processen bewijst alleen maar dat de norm het bij het rechte eind heeft en informatiebeveiliging de hele organisatie aangaat.

Kernbegrippen ISO/IEC 27001

  1.  Begrijp de context van de organisatie, zodat de scope realistisch en naar verwachting is.
  2. Zoek managementondersteuning en leiderschap.
  3. Ontwikkel een praktisch en bruikbaar ISMS.
  4. Zorg voor bewustwording en competentie door communicatie en opleiding.
  5. Pas het ISMS toe, behandel de risico’s.
  6. Evalueer regelmatig de werking van het ISMS.
  7. Leer en stuur bij, verbeter waar nodig.
  8. Ga terug naar 1.

5-Whys-methode

Sakichi Toyoda ontwikkelde begin vorige eeuw de 5-whysmethode om de productiemethodes bij Toyota, het bedrijf dat hij oprichtte, te verbeteren. Simpel uitgelegd wordt de feitelijke oorzaak van een probleem gevonden door gemiddeld vijf keer te vragen: waarom iets is gebeurd. Opvallend daarbij is de verschuiving van een technische oorzaak naar een organisatorisch of procesfalen.

Hoe werkt 5-whys in de praktijk? Een voorbeeld. Een website wordt gehackt en logingegevens worden misbruikt. Uit een eerste analyse blijkt dat een module van het CMS verouderd is en lekken vertoont. De tweede ‘waarom’ toont aan dat de server eigenlijk niet wordt beheerd, het is een oud ding waar niemand meer naar omkijkt. Uit de derde ‘waarom’ volgt dat de informatie-eigenaar geen weet heeft van het systeem, hij heeft ondertussen andere systemen die dit systeem al een jaar vervangen. De vierde ‘waarom’ toont een tekort in de documentatie en de procedures die ervoor moeten zorgen dat alle betrokkenen op de hoogte zijn. De vijfde ‘waarom’ toont dat er eigenlijk geen regelmatig overleg is tussen de beheerders en de informatie-eigenaar.

Het geüpdatete proces wordt onderdeel van een driemaandelijks overleg met alle betrokken partijen om de status en eventuele veranderingen te bespreken. Het oude, gehackte systeem wordt gearchiveerd.

5-Whys heeft zijn sporen verdiend in onder andere Kaizen en Six Sigma, technieken die gebruikt worden in onder andere procesverbetering in productie-omgevingen.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!