Applicaties en leveranciers binnen scope van een ISMS en hun beheersing
Wat is een ISMS? In dit artikel vertellen we je alles over het Information Security Management System.
Tobias op den Brouw is Manager Advies en Adviseur bij CertificeringsAdvies Nederland. Zijn kernwaarden zijn helderheid, samenwerken en doelgericht werken en daarmee samen veranderingen realiseren.
tobias@certificeringsadvies.nlWanneer je aan de slag gaat met informatiebeveiliging (naar een hoger niveau te tillen) dan is het gebruikelijk om een Information Security Management System (ISMS) in te richten. Het is daarbij van belang dat je bepaalt wat de ‘scope’ daarvan is. Ofwel: welke informatie, applicaties, leveranciers ed. zijn relevant voor de te leveren producten en diensten en vallen om die reden dus in scope? In dit artikel vertellen we je meer over hoe je dat kunt bepalen.
De scope van een ISMS
De scope van een Information Security Management System (ISMS) wordt normaliter beschreven als ‘de informatiebeveiliging van’, ofwel informatie die relevant is voor, te leveren producten en diensten. Voor een lezer van de scope moet duidelijk zijn waar hij/zij de informatiebeveiliging mag verwachten: er moet voldaan worden aan stakeholdereisen.
‘Relevant’ kan daarbij worden gedefinieerd als:
- Alle informatie in een organisatie, en haar te beheersen productieketen, waaronder ook alle interne ondersteunende processen.
- Een subset van bovenstaande (en de beheersing van daarbij relevante uitbestede processen).
Daarbij is het mogelijk en verstandig dat interne (informatiebeveiligings-)regels binnen een organisatie breder gelden dan de gecertificeerde scope.
Een subset kan op verschillende wijzen gespecificeerd worden, maar wordt meestal bepaald door:
- Relevante processen (inclusief uitbestede processen)
- Relevante locaties
- Relevante typen informatie
- Relevante informatiesystemen
- Relevante personen
Daarbij dient de subset zo bepaald te worden dat voldaan kan worden aan de verwachtingen van stakeholders die ontstaan door de scope.
Voorbeeld: Het uitsluiten van het interne HRM-systeem van een organisatie, wanneer haar scope alleen expliciet (de processen van) het leveren van datacenterdiensten betreft.
Voorbeeld: Bij de scope worden expliciet tien relevante applicaties benoemd en alle medewerkers die hier toegang tot hebben (of anderszins beïnvloeden/gebruiken):
- Daarbij is het realistisch dat de beheersmaatregelen van die tien applicaties kunnen verschillen. Een in-house beheerde applicatie op een server in het pand zal anders veilig worden gehouden dan de SaaS-applicatie van een ISO 27001 (en meer) gecertificeerde wereldwijde aanbieder.
Buiten de scope
Wel is noodzakelijk dat systemen, medewerkers, leveranciers of andere aspecten die buiten de scope worden gelaten, geen onbeheerst risico vormen voor de gedefinieerde scope. Iets buiten de scope verklaren betekent dus dat daar redelijkerwijs een ‘grens’ of beveiligingsmaatregel kan worden toegepast.
- Voorbeeld: Een externe IT-beheerder van een ‘geïsoleerd’ informatiesysteem dat buiten de scope valt, zou geen mogelijkheid moeten hebben tot beïnvloeden van informatie in een systeem binnen de scope.
- Voorbeeld: Een organisatie maakt gebruik van meerdere drukwerkleveranciers. Intern is bepaald dat marketingmateriaal laag geclassificeerd is. Marketingmedewerkers zijn (of het marketingproces is) daarmee de interne grens die ervoor zorgt dat niet elke drukwerkleverancier tot in detail beheerst moet worden. Mogelijk resteert één enkele drukker van hoog geclassificeerde documenten.
Bij organisaties met een IT-landschap met meerdere applicaties (lokaal, datacenter of cloud) en interne en externe beheerders is het daarom nuttig op basis van een informatie- of applicatielijst duidelijk zichtbaar te maken welke (informatie)systemen in scope zijn en waar onder andere de beheerverantwoordelijkheid (een uitbesteed proces) ligt. Het is gebruikelijk ook in een dergelijke lijst een verdere classificatie van belang (BIV) te doen om op basis daarvan ook de ‘zwaarte’ van beheersing vast te stellen. Voorbeelden zijn de omvang van toe te passen change management en teststappen bij wijzigingen aan een dergelijk systeem of de mate van controle van en eisen aan een leverancier.
Bij sterk geïntegreerde of gecombineerde clusters van informatie/systemen, met een duidelijke ‘buitengrens’, is het vaak eenvoudiger deze integraal binnen scope te nemen in plaats van hier scope nuances aan te brengen.
Relevante eisen aan leveranciers
Wat zijn dan relevante eisen aan leveranciers? Praktisch uitgangspunt is dat de leverancier een passende beheersing moet krijgen [ISO 27001 8.1].*
- Voorbeeld: Een leverancier van een fysiek product kan zeer beperkte formele eisen krijgen indien de organisatie zelf een zeer uitgebreide controle doet van dat product voordat ze het in gebruik neemt.
- Voorbeeld: Een leverancier van maatwerksoftware kan óf zijn gehele ontwikkelstraat en testresultaten laten zien, of de software kan intern getest worden.
Leveranciers die de scope kunnen beïnvloeden, moeten zijn geïnformeerd over de voor hen relevante regels uit het managementsysteem [ISO 27001 5.2g].
- Voorbeeld: Een monteur die in een serverruimte werkt moet de regels kennen van de apparatuur waar hij bij kan. De regels van een tweede ruimte waar hij niet bij kan, hoeft hij niet te kennen.
Breder gesproken kunnen leveranciers op meerdere plaatsen een rol krijgen in het managementsysteem [ISO 27001 5.3], bijvoorbeeld bij inhuur van een Security Officer, of kennis moeten nemen van doelstellingen en beleid waar zij aan moeten bijdragen [ISO 27001 6.2h, 7.3]. Eenvoudig gezegd: zorg dat belangrijke leveranciers een duidelijke taak krijgen, competent personeel leveren en weten wat ze moeten doen (dit komt in vervolgeisen hieronder ook terug):
- Mogelijk moet er structureel of projectgebonden overleg zijn met deze leveranciers [ISO 27001 7.4], of rapportage [7.5] ten behoeve van monitoring [9.1].
- Het is mogelijk dat de organisatie ervoor kiest om de leverancier zelf te ‘auditen’ of anderszins te monitoren [ISO 27001 9.2]. Dit is in veel gevallen al bedongen in een verwerkersovereenkomst met die leverancier [ISO 27001 A.18.1.4] en gebruikelijker bij hoge afhankelijkheid van een niet ISO 27001 gecertificeerde leverancier.
- Het is gebruikelijk de relevante leveranciers te beoordelen bij directiebeoordeling [ISO 27001 9.1, 15.2.1].
Het hangt uiteraard af van wat de dienstverlening inhoudt welke uitvoerende taken en relevante beheersmaatregelen men dient na te leven. De eisen aan iemand die back-ups uitvoert [ISO 27001 A.12.3.1] zullen anders zijn dan die aan een organisatie die nieuwe medewerkers helpt screenen [ISO 27001 A.7.1.1]. Leveranciers welke op locatie komen, zullen meestal worden behandeld als bezoeker [ISO 27001 A.11] en zich mogelijk aan bedieningsprocedures moeten houden [ISO 27001 A.12.1.1]. Dat gezegd hebbende, zijn er een aantal beheersmaatregelen waar expliciet aandacht gevraagd wordt:
- Leveranciers die feitelijk werken als personeel dienen beheerst te worden conform A.7, veilig personeel, en zich verder aan alles te houden dat regulier personeel ook dient te doen. Hiertoe dient meestal het reguliere HRM proces.
- Leveranciers die toegang tot informatie(systemen) krijgen, zijn een vorm van gebruiker. Er moet dus worden bepaald wie waartoe toegang krijgt conform A.9. Hiertoe dient meestal een intern IT-beheer proces.
- Daar waar de leverancier belangrijk is voor informatietransport, moeten er overeenkomsten zijn [ISO 27001 A.13.2.2].
- Leveranciers zullen zich moeten houden aan geheimhoudingovereenkomsten, passend bij de behoefte van de organisatie [ISO 27001 A.13.2.3].
- Er dient expliciet supervisie en monitoring te zijn voor eventuele uitbestede softwareontwikkeling [ISO 27001 A.14.2.7].
* Daarbij is het aannemelijker dat ISO 27001 gecertificeerde leveranciers (met de juiste scope en verklaring van toepasselijkheid) zaken goed beheersen indien er een goed contract met die leverancier ligt. De externe auditor van die leverancier dient namelijk te controleren of dat bedrijf in staat is aan de stakeholdereisen te voldoen. Daarbij is er natuurlijk geen garantie dat bij die externe audit de steekproeven zo genomen zijn dat er voldoende vertrouwen ontstaat in de praktijk. Een alternatief kan de ISAE 3402 zijn.
Eisen met betrekking tot de leveranciersrelatie
Met betrekking tot de leveranciersrelatie, zijn er de volgende expliciete eisen (bron: NEN ISO 27002):
- “Met de leverancier behoren de informatiebeveiligingseisen om risico’s te verlagen die verband houden met de toegang van de leverancier tot de bedrijfsmiddelen van de organisatie, te worden overeengekomen en gedocumenteerd.” Dit ziet toe op de sturing hiervan door middel van beleid, dat over het algemeen gestandaardiseerd wordt voor alle leveranciers (met nuances n.a.v. de daadwerkelijke dienstverlening, zie volgende punt).
- “Alle relevante informatiebeveiligingseisen behoren te worden vastgesteld en overeengekomen met elke leverancier die toegang heeft tot IT-infrastructuurelementen ten behoeve van de informatie van de organisatie, of deze verwerkt, opslaat, communiceert of biedt.”. Hierbij is van belang dat er een overeenkomst is die, na overweging, de relevante voorwaarden bevat. Het kan zijn dat de organisatie akkoord gaat met het aanbod van een leverancier (bijvoorbeeld met grote SaaS leveranciers).
- “Overeenkomsten met leveranciers behoren eisen te bevatten die betrekking hebben op de informatiebeveiligingsrisico’s in verband met de toeleveringsketen van de diensten en producten op het gebied van informatie- en communicatietechnologie”. Dit wordt tegenwoordig vaak gedekt door bepalingen in de verwerkersovereenkomst onder de Algemene Verordening Gegevensbescherming (AVG).
- “Organisaties behoren regelmatig de dienstverlening van leveranciers te monitoren, te beoordelen en te auditen.” Zie de opmerkingen hierboven.
- “Veranderingen in de dienstverlening van leveranciers, met inbegrip van handhaving en verbetering van bestaande beleidslijnen, procedures en beheersmaatregelen voor informatiebeveiliging, behoren te worden beheerd, rekening houdend met de kritikaliteit van bedrijfsinformatie, betrokken systemen en processen en herbeoordeling van risico’s.” De leverancier moet niet zomaar eenzijdig zijn dienstverlening (kunnen) veranderen.
Op basis van o.a. de AVG/GDPR zal ook bedongen zijn dat de leverancier melding doet van datalekken. Het is daarnaast ook de bedoeling dat de leverancier relevante incidenten of kwetsbaarheden meldt [ISO 27001 A.16.1.2].
Martijn Stuart (Infield ICT) vertelt over de samenwerking met CAN: “Het was daarbij heel prettig dat er via CAN een ondersteunend systeem beschikbaar was in de vorm van Atlassian Confluence waarin we ons Information Security Management System (ISMS), samen met CAN, hebben opgezet. Voor ons was het belangrijk bij die keuze dat het vanaf dag één ons eigen systeem zou worden en dat het geen ‘ISO handboek’ zou zijn. We wilden het echt doorleven en implementeren.” Lees de hele klantcase van Infield ICT.
Conclusie
Op basis van de bovenstaande informatie en set aan eisen dient bepaald te worden welke leveranciers relevant zijn en met deze leveranciers zullen er dus overeenkomsten moeten zijn. Voor dat laatste is het verstandig de ISO 27002 normtekst, hoofdstuk 15 leveranciersbeheersing (gelijk aan ISO 27001 Annex A 15) bij NEN aan te schaffen, en in detail door te lezen.
Praktisch gezien zal er vaak een algemeen geldend leveranciersbeleid zijn dat aan de inkoopverantwoordelijke (of bevoegden) de taak geeft om per leverancier:
- Het algemeen geldende informatiebeveiligingsbeleid van de organisatie aan die leverancier op te leggen
- Samen met de Security Officer te reviewen welke expliciete overeenkomst en aantoonbaar bewijs van naleving daarvoor met de leveranciers in scope nodig zijn.
Kun je hulp gebruiken bij het bepalen van de scope en/of het inrichten van je ISMS? Of wil je meer weten over informatiebeveiliging/ISO 27001 voor jouw organisatie? Neem dan gerust contact met ons op. Onze adviseurs helpen je graag op weg.
Transcriptie video: Wat is een ISMS? (ISO 27001)
Wat is een ISMS? Goede vraag! Een ISMS is in goed Nederlands een Information Security Management System. Of in iets beter Nederlands: een Informatiebeveiligingsmanagagmentsysteem. Maar dat gebruikt bijna niemand. ISMS is wat gangbaarder, want technisch werkveld dus Engels jargon. De soms voorkomende misvatting is dat een ISMS, omdat we het over een technisch discipline hebben wat veel IT-bedrijven hanteren, dat dat een softwaretool moet zijn. En dat is niet zo. Een Information Security Management System is een werkwijze om een thema, namelijk informatiebeveiliging, te managen. Als jij die werkwijze bij wijze van spreken kan met een aantal mooie Word- en Excel documenten, dan heb jij geen andere softwaretool nodig dan anders dan wat je bij veel organisaties ziet: SharePoint om documenten in te plaatsen.Het mooie van een digitale tool is wel dat als je een keuze hebt: beschrijf ik een bepaalde manier van werken door een A4’tje te beschrijven of het in een workflow in een tool te zetten? Beide is toegestaan. Dus als jij door middel van een tool het makkelijker uitvoerbaar maakt dan is dat een mooie bonus, maar niet verplicht.
Tobias op den Brouw is Manager Advies en Adviseur bij CertificeringsAdvies Nederland. Zijn kernwaarden zijn helderheid, samenwerken en doelgericht werken en daarmee samen veranderingen realiseren.
tobias@certificeringsadvies.nl
Meer weten over ISO 27001?
Download de handige informatiegids!
- Alles over informatiebeveiliging
- Stap voor stap inzicht
- Antwoord op al je vragen
