Dus je hebt na tijdenlang twijfelen eindelijk de beslissing genomen om te beginnen met het opzetten van een ISMS1 op basis van de bekende ISO2 27000 standaard, en/of de daarvan afgeleide NEN3 7510, maar je hebt geen idee hoe dit aan te pakken.
Het managementteam ziet wel enige toegevoegde waarde, maar is vooral geinteresseerd
omdat de klanten steeds vaker beginnen te vragen om dergelijke certificaten, en in
de meeste RFPs4 is opgenomen dat de leverancier beschikt over een ISO 27001
certificaat, en je niet eens hoeft te reageren op een dergelijk verzoek als je hier
niet aan voldoet.
Het enige waar zowel het management als je directe collega’s niet op zitten te wachten
is de vaak gehoorde klacht dat het verspilde resources zijn, die een of meerdere dikke
ordners gevuld met beleid, procedures en richtlijnen gaan opleveren die uiteindelijk
alleen stof gaan verzamelen op de bovenste plank van de archiefkast. Dat, en natuurlijk
de gevreesde, immer terugkernde interne, maar vooral externe, audits die aan moeten
tonen dat de organisatie nog steeds ‘in control’ is en er gewerkt wordt aan een
constante verbetering.
Maar is het werkelijk zo erg? Of moet het werkelijk de verwezelijking zijn van het hier boven beschreven doom-scenario? Als je eerlijk bent, dan is een constante verbetering van (bedrijfs)processen iets waar elke organisatie mee bezig zou moeten zijn. Al was het alleen maar om hun concurrentiepositie niet te verliezen. En als je een proces als het opstarten van een ISMS alleen zou doen om papier te vullen met beleidstukken, procedures en richtlijnen die daarna in een kast kunnen verdwijnen dan heb je het werkelijk niet begrepen.
Oke, het bovenstaande geeft je een beeld van wat het allemaal niet is en ook een beetje een inkijk in waarom het wel een goed idee zou zijn, maar als je dan de standaard gaat zitten lezen dan zakt de moed je waarschijnlijk weer in de schoenen, en het bovenstaande doom-scenario komt in alle heftigheid weer op je af (of in alle eerlijkheid val je in slaap na het lezen van enkele regels tekst).
Maar zoals we meerdere keren op de website aangeven staan wij een no-nonsens / no-hype aanpak van informatiebeveiliging, dus ook bij het opzetten en implementeren van een ISMS op basis van ISO 27001 en/of NEN 7510. De reden om dit op te zetten is:
- Beleid, procedures en richtlijnen op belangrijke onderdelen van informatiebeveiliging vastleggen in duidelijk leesbare documenten die door alle (nieuwe) medewerkers ingezien kunnen worden waardaar deze direct op de hoogte zijn van de manier zoals de organisatie hiermee omgaat.
- Voortdurend werken aan het handhaven of verbeteren van de beveiliging van informatie (zowel opgeslagen als in transit).
- Bewijs verzamelen om aan te kunnen tonen dat bovenstaande punten werkelijk geimplementeerd zijn en dagelijks gebruikt worden.
Kortom, als je het bovenstaande leest betekent het dat:
“Je beschrijft wat je doet, en doet wat je hebt beschreven.”
Een credo dat ik persoonlijk hartgrondig onderschrijf.
Voor kleine tot middelgrote organisaties (maar ik maak me sterk dat dit ook voor
grote multinationals kan) betekent dit dat je heel pragmatisch te werk kunt gaan,
waardoor er geen uitgebreide volumes aan papier gevuld hoeven te worden, maar wel
de verschillende onderdelen op een duidelijk leesbare manier moeten worden
beschreven. Het opzetten van een informatiebeveiligingshandboek waarin de belangrijkste
onderdelen die voor alle medewerkers (en waarschijnlijk zelfs voor externen die
werkzaamheden voor de organisatie willen uitvoeren) gelden kan hierbij een zeker
een hulp zijn.
Onderdelen die je in een dergelijk handboek kunt beschrijven zijn ondermeer (maar
zeker niet uitsluitend):
- Fysieke beveiliging, zowel van kantoren als van laptops en informatie op papier;
- Gebruik van sterke cryptografie, wachtwoorden, MFA5, en wachtwoordkluizen;
- Regels gesteld aan BYOD6, toegang tot centrale systemen en gebruik van VPN7;
- Gebruik van bedrijfse-mail, en social media;
- Op welke wijze backups gemaakt worden van de systemen en hoe deze regelmatig getest moeten worden;
- Op welke wijze (grotere) bestanden uitgewisseld kunnen worden – zowel onderling tussen medewerkers van de organisatie als met externen;
- Hoe omgegaan moet worden met social engineering aanvallen.
Uit het bovenstaande kun je opmaken dat een relevant gedeelte van de noodzakelijke vastlegging nu al heeft plaatsgevonden. Natuurlijk is dit handboek, net als alle overige documenten een zogenaamd levend document. Dit betekent dat het regelmatig zal worden gecontroleerd, en wanneer noodzakelijk wordt aangepast of aangevuld.
Elke ISMS heeft unieke aspecten die van toepassing zijn op de implementerende
organisatie. Dat je daarvoor een goed idee moet hebben van de organisatie lijkt me
duidelijk. Vandaar dat je, naast het hiervoor genoemde handboek, als een van de
eerste documenten die je gaat opleveren de ‘context van de organisatie’ gaat
beschrijven. Het opstellen hiervan kan in de meeste gevallen niet zonder de nodige
input van het managementteam.
Een beperkte inhoudsopgave kan bestaan uit de volgende onderdelen:
- Introductie: Wie zijn we, en waar komen we vandaan?
- Missie, visie en waarden (veelal gebaseerd op ‘waarom’, ‘wat’ en ‘hoe’).
- Onze belanghebbenden (zowel intern als extern) en hun verwachtingen.
- SWOT8 analyse
- Conclusie
Een versie zonder de noodzakelijke SWOT analyse kan ook openbaar gemaakt worden, maar de volledige versie van dit document wordt hoogstwaarschijnlijk als ‘Restricted – Internal use only’ geclassificeerd.
Op basis van dit document kan daarna, in samenwerking met een of meerdere medewerkers van de organisatie, een eerste risicoanalyse gemaakt worden. Veelal gebeurt dit op basis van een uitgebreide lijst potentiele risico-scenario’s die (uitgebreid) besproken worden met deze ervaringsexperts. Dit overzicht en de uitgewerkte rapportage wordt door een consultant gebruikt als initiele input voor het opstellen van de SoA9 en ‘Gap Analysis’ (veelal ondergebracht in een uitgebreide spreadsheet die tevens gebruikt kan worden als dashboard), maar zal daarnaast ook richting geven aan het opstellen van de eerste interne audit, aangezien hier zeker verbeterpunten zijn te vinden.
Tot zover een eerste blog over een pragmatische opzet van een ISMS gebaseerd op ISO 27000 en/of NEN 7510. Ik hoop dat het bovenstaande je een beeld heeft gegeven van hoe het opzetten hiervan in principe geen waanzinnig groot project hoeft te zijn, maar voor een middelgrote organisatie waarschijnlijk in slechts 1-2 manmaanden inspanning kan worden verwezenlijkt (natuurlijk altijd afhankelijk van de mogelijke inzet van overige resources). Waar je natuurlijk wel van doordrongen moet zijn is dat het werken met een ISMS geen project is, maar een voordurend proces waarmee de organisatie:
- Laat zien dat ze informatiebeveiliging belangrijk vindt;
- Laat zien dat ze resources beschikbaar stelt om de informatie ook werkelijk veilig te houden;
- Laat zien dat ze (waar nodig) voortdurend verbeteringen aanbrengt in het beleid, de procedures en richtlijnen.
Wellicht dat ik in een volgende blog bepaalde zaken nog wat verder zal uitwerken. Laat in elk geval weten wat je hiervan vindt en waar mogelijke interesses liggen, dit kan via het contactformulier op deze website, of via een directe e-mail.
Information Security Management System ↩︎
International Standard Organisation (https://www.iso.org/home.html) ↩︎
De Stichting Koninklijk Nederlands Normalisatie Instituut (https://www.nen.nl) ↩︎
Request for Proposal – Veelal een uitgebreide vragenlijst opgesteld door de inkoopafdeling van grotere organisaties, gestuurd aan meerdere potentiele aanbieders, om te helpen bij de selectie van de meest passende offerte ↩︎
Multi Factor Authentication (ook soms 2FA genoemd indien er van twee onafhankelijke authenticatiemethoden gebruik wordt gemaakt) ↩︎
Bring Your Own Device ↩︎
Virtual Private Network ↩︎
Strength, Weaknesses, Opportunities, Threats ↩︎
Statement of Applicability (In het Nederlands leidt dit in eerste instantie wel vaker tot mogelijke misverstanden) ↩︎