Waarom de bedrijfsmiddelen in je ISMS geen kopie van je CMDB zijn

Bijna elke organisatie die met een ISMS begint, komt op hetzelfde punt uit. Er is al een CMDB met duizenden configuratie-items, netjes bijgehouden door het beheerteam, en de vraag ligt voor de hand. Zetten we die lijst over naar het ISMS? Het antwoord is nee. Wie dat toch doet, zit binnen een week met een register dat niemand onderhoudt en een classificatiekolom die leeg blijft. Het verschil tussen de twee registers begrijpen scheelt je maanden werk. Voor financiële entiteiten die onder DORA vallen ligt het genuanceerder, en daar komen we verderop apart op terug.

Eén woord, twee betekenissen

Het woord “asset” heeft in de ICT twee betekenissen die toevallig dezelfde term delen.

In de beheerwereld, dus in ITIL en ISO/IEC 20000, is een configuratie-item alles wat je moet kennen om een dienst te kunnen leveren en wijzigen, zoals servers, virtuele machines, netwerkcomponenten, licenties en koppelingen. Het register bestaat om wijzigingen, incidenten en capaciteit te kunnen beheersen. Volledigheid en actualiteit zijn daarbij de belangrijkste kwaliteitseisen.

In de beveiligingswereld, dus in ISO/IEC 27001 en in BIO 2.0, is een bedrijfsmiddel iets waar een eigenaar bij hoort die er een besluit over kan nemen. Beheersmaatregel 5.9 vraagt om een inventaris van informatie en andere gerelateerde bedrijfsmiddelen, met een eigenaar per onderdeel. Die eigenaarseis is niet administratief bedoeld, want zonder eigenaar is er niemand die het restrisico kan aanvaarden.

De twee registers beantwoorden dus verschillende vragen. Je CMDB beantwoordt de vraag wat je hebt staan en hoe het samenhangt. Je ISMS-register beantwoordt de vraag wat je moet beschermen, hoe zwaar, en wie daarover beslist. Dat zijn geen twee versies van dezelfde lijst, maar twee lijsten op een ander abstractieniveau.

Onderzoekers wezen hier al vroeg op. Oppenheim, Stenson en Wilson lieten in hun werk over informatie als bedrijfsmiddel zien dat informatie zich anders gedraagt dan een klassiek activum, omdat informatie niet slijt, tegelijk op meerdere plaatsen kan bestaan en waarde ontleent aan de context waarin ze wordt gebruikt. Een boekhoudkundige of technische inventarisatielogica sluit daar slecht op aan.

De vier lagen

Het helpt om bedrijfsmiddelen in vier lagen te ordenen. Elke laag heeft een eigen soort eigenaar en een eigen soort vraag.

1. Het bedrijfsproces, bijvoorbeeld salarisverwerking, studentinschrijving of orderafhandeling. De eigenaar is de proceseigenaar, en die kan zeggen hoe lang het proces stil mag liggen voordat er echte schade ontstaat.
2. De informatie of gegevensverzameling die in dat proces omgaat, zoals personeelsdossiers, examenresultaten of klantcontracten. Hier grijpt de BIV-waardering aan, en de eigenaar is de verantwoordelijke voor die gegevens.
3. De applicatie of dienst die het proces ondersteunt. Die erft zijn classificatie van de zwaarst gewaardeerde informatie die erin wordt verwerkt.
4. De onderliggende techniek, met servers, opslag, netwerkcomponenten en koppelingen. Dit is het terrein van je CMDB.

Een ISMS werkt op laag 1 tot en met 3. Je CMDB werkt op laag 4 en soms op laag 3, want daar raken de twee registers elkaar. Precies op dat raakvlak leg je de koppeling, en nergens anders.

BIV waardeer je op informatie, niet op ijzer

Een databaseserver is niet vertrouwelijk. De gegevens die erop staan zijn dat wel. Dat klinkt als een woordenspel, maar het is het hele verschil tussen een classificatie die werkt en een classificatie die papier blijft.

De waardering van Beschikbaarheid, Integriteit en Vertrouwelijkheid is geen etiket op zichzelf, maar een schakelaar. Een classificatie is pas zinvol als er iets uit volgt. Denk daarbij aan de volgende gevolgen:

• Welke maatregelen uit de basisbeveiliging verplicht zijn en welke aanvullende maatregelen daar bovenop komen.
• Welke hersteltijd en welk maximaal gegevensverlies gelden, dus de RTO en RPO uit je continuïteitsanalyse.
• Hoe zwaar het toegangsbeheer, de logging en de bewaartermijnen moeten zijn.
• Of er een aparte risicoanalyse of een DPIA nodig is voordat de verwerking mag starten.

Waardeer je op laag 4, dan waardeer je hardware, en aan hardware valt geen zinnig bedrijfsbelang toe te kennen. Een server heeft pas een beschermingsniveau nodig zodra je weet welke informatie erop staat.

De Amerikaanse overheidsnorm werkt precies zo. FIPS 199 categoriseert langs dezelfde drie eigenschappen als BIV, met de niveaus laag, gemiddeld en hoog, en hanteert daarbij het hoogste-waarde-principe (in het Engels bekend als de high water mark). De categorie van een systeem is gelijk aan de hoogste waardering van alle informatiesoorten die het systeem verwerkt. NIST SP 800-60 werkt dat uit in tabellen die informatiesoorten aan categorieën koppelen. Dat is dezelfde overerving die je in Kantyra van informatie naar applicatie ziet lopen.

Dat principe heeft ook een keerzijde die je moet kennen. Wie het hoogste-waarde-principe klakkeloos toepast, brengt hele omgevingen onder het zwaarste regime omdat er één gevoelige gegevensverzameling in meedraait. Dat is precies de reden waarom NIST in SP 800-53 ruimte laat voor het bijstellen van de maatregelenset, en waarom scheiding van omgevingen vaak goedkoper uitpakt dan alles naar het hoogste niveau tillen. Als één toepassing je hele domein naar het niveau kritiek trekt, is de vraag niet hoe je dat betaalt, maar of die toepassing daar wel thuishoort.

Let daarnaast op het aggregatie-effect. Losse gegevens kunnen ieder afzonderlijk laag scoren, terwijl de verzameling als geheel gevoelig wordt. Een lijst met alleen postcodes is onschuldig, maar dezelfde lijst gekoppeld aan afwezigheidsregistratie is dat niet meer.

Wat onderzoek laat zien over classificatie die vastloopt

Informatieclassificatie is een van de weinige onderwerpen binnen informatiebeveiliging waar wel serieus empirisch onderzoek naar is gedaan, met name uit Zweeds onderzoek naar publieke organisaties. De bevindingen komen opvallend consistent terug, en ze verklaren waarom zoveel classificatietrajecten stranden.

Organisaties classificeren in de praktijk systemen in plaats van informatie, omdat systemen tastbaar zijn en in een lijst staan. Daarmee verdwijnt de koppeling met het bedrijfsbelang en blijft er een technische inventarisatie over. De classificatieschema's zijn bovendien vaak te fijnmazig, met te veel niveaus en te veel dimensies, waardoor de mensen die ze moeten toepassen afhaken. Het werk wordt daarna alsnog gedaan door de beveiligingsfunctionaris of de ICT-afdeling in plaats van door de eigenaar, en juist dat ondermijnt de bedoeling, want een classificatie is een uitspraak over bedrijfsbelang en niet over techniek. Ten slotte wordt classificatie behandeld als een eenmalige oefening voor de auditor, terwijl processen en gegevensstromen jaarlijks veranderen.

De rode draad in die bevindingen is dat classificatie mislukt zodra ze wordt losgekoppeld van de mensen die het belang kennen en van de maatregelen die eruit volgen. Dat is meteen de belangrijkste ontwerpeis voor elk ISMS-register, want elke regel hoort een eigenaar met een naam te hebben, en elke waardering hoort aantoonbaar iets te veranderen aan wat er moet gebeuren.

Dat sluit ook aan bij de Nederlandse bestuurlijke verhoudingen. De CISO is in ons governancemodel niet de risico-eigenaar. De proces- of systeemeigenaar bezit het risico en aanvaardt het restrisico, en het bestuur is uiteindelijk aanspreekbaar. Een classificatie die door de beveiligingsafdeling is ingevuld, legt dus een oordeel vast dat die afdeling helemaal niet mag geven.

Wel of niet koppelen aan de CMDB

Het praktische advies is om geen synchronisatie te bouwen, maar wel een verwijzing te leggen. Er zijn drie varianten, oplopend in kosten en in onderhoudslast.

Bij de eenvoudigste variant leg je in je ISMS per applicatie het CI-nummer uit de CMDB vast als los veld. Een auditor kan die verwijzing volgen, je hebt er geen techniek voor nodig en je bent in een middag klaar. Voor de meeste organisaties is dit genoeg.

Bij de tweede variant doe je een eenmalige import van een deelverzameling. Je exporteert uit de CMDB alleen de configuratie-items van het type applicatie of bedrijfsdienst, en gebruikt die als startlijst. Daarna onderhoud je beide registers los van elkaar, want ze veranderen om verschillende redenen.

De derde variant is een periodieke koppeling, en die is alleen zinvol als je CMDB aantoonbaar actueel is en er per configuratie-item een duidelijke eigenaar in staat. Bij de meeste organisaties is dat niet het geval, en dan importeer je vooral vervuiling.

Belangrijker dan de techniek is de richting van het verkeer, want die loopt twee kanten op. Naar beneden gaat de classificatie. Als een applicatie hoog scoort op beschikbaarheid, moeten de servers eronder het bijbehorende back-up-, patch- en bewakingsregime krijgen, en dat is de reden waarom je de koppeling überhaupt legt. Naar boven gaan de technische feiten, dus welke componenten deze applicatie dragen, waar ze staan en wat de patchstatus is. De eerste richting is de waardevolle, omdat je classificatie dan het beheer aanstuurt in plaats van een papieren oefening te blijven.

Deze drie varianten volstaan voor organisaties die werken vanuit ISO/IEC 27001, BIO 2.0 of de Cyberbeveiligingswet. Val je onder DORA, dan is de eerste variant te licht, en dat leggen we in de volgende paragraaf uit.

Vier kaders, één onderwerp

De gelaagde logica houdt stand onder de verschillende kaders, maar de as waarlangs je classificeert verschilt per kader. Precies daar gaat het vaak mis, want organisaties bouwen dan drie registers naast elkaar terwijl het onderwerp hetzelfde is.

De eerste drie rijen gaan over hetzelfde onderwerp, alleen met een andere juridische bril. De vierde rij gaat over iets anders.

De Cbw grijpt aan op de dienst

De Cyberbeveiligingswet werkt op het niveau van de dienst. Of je onder de wet valt, hangt af van je sector en van de dienst die je levert, en niet van je systemen. De zorgplicht vraagt om passende en evenredige maatregelen op basis van een risicobeoordeling, waarbij het beheer van bedrijfsmiddelen en het toegangsbeleid met zoveel woorden in de maatregelencategorieën staan.

Het woord “evenredig” doet daarbij het werk. Evenredigheid kun je alleen onderbouwen als je weet welk bedrijfsbelang achter een systeem schuilgaat, en dat is nu juist wat een BIV-waardering vastlegt. Zonder classificatie heb je geen verdedigbaar antwoord op de vraag waarom je bij het ene systeem wel een tweede uitwijklocatie hebt ingericht en bij het andere niet. De meldplicht werkt op dezelfde manier, want de drempel hangt af van de gevolgen voor je dienstverlening, en die beoordeel je op procesniveau.

De bestuurlijke kant versterkt het punt over eigenaarschap. Het bestuur moet de maatregelen goedkeuren en toezien op de uitvoering, en is daarop aanspreekbaar. Een classificatie die de beveiligingsafdeling zelf heeft ingevuld, legt dan een oordeel vast dat het bestuur zou moeten dragen.

DORA vraagt om beide registers tegelijk

DORA is de uitzondering op de stelling waarmee dit artikel begint, en dat is de moeite waard om precies te krijgen.

Wie artikel 8 leest, ziet in lid 4 en lid 6 iets wat functioneel gewoon configuratiebeheer is. Je moet alle informatie- en ICT-bedrijfsmiddelen identificeren, ook die op externe locaties, inclusief netwerkbronnen en apparatuur, en je moet de configuratie en de onderlinge verbindingen en afhankelijkheden in kaart brengen en die inventarissen bijhouden. Dat is aanzienlijk concreter dan ISO/IEC 27001, want beheersmaatregel 5.9 zegt niets over configuraties of afhankelijkheden. Wie hieruit concludeert dat DORA vooral een CMDB voorschrijft, heeft dus een punt.

Toch is het dat niet, en de verordening maakt dat zelf duidelijk in haar definities. DORA onderscheidt het ICT-bedrijfsmiddel, dus een software- of hardwaremiddel in de netwerk- en informatiesystemen, van het informatiemiddel, dus een verzameling informatie die het beschermen waard is. Dat is exact de scheiding tussen de lagen die hierboven staat beschreven, en de wetgever heeft haar in de begripsbepalingen vastgelegd in plaats van beide op één hoop te gooien.

Lid 1 is bovendien geen inventarisatievraag. Daar staat dat je de door ICT ondersteunde bedrijfsfuncties moet identificeren, classificeren en documenteren, samen met de rollen en verantwoordelijkheden, en met de informatie- en ICT-bedrijfsmiddelen die die functies ondersteunen, telkens in relatie tot het ICT-risico. Een gemiddelde CMDB levert dat niet, want daarin ontbreekt het volgende:

• Er staat hooguit een technisch beheerder in, en niet een eigenaar die het restrisico kan aanvaarden.
• De koppeling van een component naar de bedrijfsfunctie die het ondersteunt ontbreekt, en daarmee ook de reden waarom dat component ertoe doet.
• Het oordeel over kritikaliteit komt er niet uit voort, omdat dat oordeel uit de bedrijfsfunctie volgt en niet uit de techniek.
• Er is geen periodieke herziening waarin iemand bevestigt dat de classificatie nog klopt, terwijl DORA om een actualisering vraagt en om een risicobeoordeling bij elke ingrijpende wijziging.
• Verouderde systemen en de afhankelijkheid van derde ICT-dienstverleners krijgen geen aparte aandacht, terwijl artikel 8 daar afzonderlijke leden aan wijdt.

De scherpe formulering is daarom dat DORA niet om een CMDB vraagt en ook niet om een klassiek bedrijfsmiddelenregister, maar om de combinatie van beide met een aantoonbare koppeling ertussen. Een CMDB alleen is te technisch en mist de functie, de eigenaar en de kritikaliteit. Een klassiek register alleen is te abstract en mist de configuratie en de afhankelijkheden. De technische regelgeving bij de verordening werkt dat verder uit met eisen aan wat de inventaris per bedrijfsmiddel moet bevatten.

Praktisch betekent dat voor financiële entiteiten dat een enkel verwijsveld met het CI-nummer niet volstaat. Je hebt een onderhouden koppeling nodig waarin de kritikaliteit van boven naar beneden overerft naar de technische componenten en waarin de afhankelijkheden zichtbaar blijven. Reken daarbij ook op een derde register dat niets met de eerste twee te maken heeft, namelijk het informatieregister over de contractuele afspraken met ICT-dienstverleners. Dat kent een voorgeschreven datamodel met vaste sjablonen en gaat naar de toezichthouder, dus wie dat in dezelfde tabel als zijn bedrijfsmiddelen probeert te persen, loopt vast.

Eén register, meerdere kenmerken

De praktische uitkomst is dat je één register aanhoudt op proces- en informatieniveau, met per kader een eigen kenmerk op dezelfde regel. Een proces krijgt dus een BIV-waardering, daarnaast een kenmerk of het onder de Cbw meetelt als essentiële of belangrijke dienst, en voor financiële entiteiten een kenmerk of het een kritieke of belangrijke functie is.

Leid die kenmerken niet automatisch uit elkaar af. Een hoge score op vertrouwelijkheid maakt iets nog geen kritieke functie onder DORA, en een kritieke functie hoeft niet hoog te scoren op vertrouwelijkheid. Het zijn juridische kwalificaties met eigen criteria, en software die ze automatisch van elkaar overneemt, levert een verkeerd beeld op dat er wel netjes uitziet.

Hoe groot moet het register zijn

Een werkbaar ISMS-register telt bij de meeste organisaties tussen de vijftig en honderd bedrijfsmiddelen. Zit je op duizenden regels, dan heb je je CMDB gekopieerd.

De toets per regel is eenvoudig. Is er een persoon met een naam die voor dit bedrijfsmiddel het restrisico kan aanvaarden? En verandert er iets aan de maatregelen door de classificatie die je eraan hangt? Beantwoord je een van beide vragen met nee, dan hoort de regel thuis in je CMDB en niet in je ISMS.

Onder DORA blijft die vuistregel gelden voor de bovenste lagen, maar daar komt de volledige inventaris van ICT-bedrijfsmiddelen bij, en die is per definitie omvangrijker. Het verschil is dat je die twee gescheiden houdt en met elkaar verbindt, in plaats van ze tot één lijst te vermengen.

In zeven stappen

1. Begin bij de bedrijfsprocessen en niet bij de systemen, en houd het aantal beperkt tot de processen die er werkelijk toe doen.
2. Benoem per proces de eigenaar, en leg die naam vast voordat je verder gaat.
3. Breng per proces de informatie in beeld die erin omgaat, en waardeer die op beschikbaarheid, integriteit en vertrouwelijkheid.
4. Koppel de applicaties aan die informatie en laat de classificatie overerven van de zwaarst gewaardeerde gegevensverzameling.
5. Leg per applicatie de verwijzing naar het configuratie-item in je CMDB vast, zonder de technische gegevens over te nemen. Val je onder DORA, leg dan een onderhouden koppeling naar de onderliggende componenten en hun afhankelijkheden.
6. Vertaal de classificatie naar concrete eisen, dus naar maatregelen, hersteltijden en bewaartermijnen, en geef die door aan het beheer.
7. Herzie de waardering jaarlijks en bij elke wijziging van betekenis, en laat de eigenaar die herziening bevestigen.

Deze volgorde is voor een deel van de organisaties bovendien geen vrije keuze. Zowel de Cyberbeveiligingswet als DORA verlangt dat je maatregelen in verhouding staan tot het risico, en die verhouding kun je alleen onderbouwen als je weet welk bedrijfsbelang achter een systeem schuilgaat. Een technische inventarisatie alleen levert die onderbouwing niet, en een classificatie zonder koppeling naar de techniek levert geen aantoonbare uitvoering op. Je hebt ze allebei nodig, maar wel als twee registers die je verbindt.

Bronnen

Normatieve bronnen, rechtstreeks na te slaan:

• ISO/IEC 27001:2022, beheersmaatregelen 5.9 (inventaris van informatie en andere gerelateerde bedrijfsmiddelen), 5.10, 5.12 (classificatie van informatie) en 5.13 (labelen van informatie), met de toelichting in ISO/IEC 27002:2022.
• BIO 2.0, die de structuur van ISO/IEC 27002:2022 volgt, in samenhang met de Cyberbeveiligingswet als Nederlandse uitwerking van de Europese NIS2-richtlijn.
• Verordening (EU) 2022/2554 (DORA), artikel 3 voor de begripsbepalingen van het ICT-bedrijfsmiddel en het informatiemiddel, en artikel 8 voor identificatie, classificatie en documentatie van bedrijfsfuncties en bedrijfsmiddelen. Neem de definities uit artikel 3 letterlijk over wanneer je hierover intern beleid schrijft, en betrek daarbij de technische reguleringsnormen bij de verordening voor de eisen aan de inventaris.
• De Cyberbeveiligingswet, in het bijzonder de zorgplicht met de maatregelencategorieën en de meldplicht, samen met de sectorale regelingen die daaronder hangen. Controleer de actuele stand van inwerkingtreding en van die regelingen voordat je je erop beroept.
• ISO/IEC 20000-1 en de ITIL 4-praktijk voor dienstconfiguratiebeheer, voor de betekenis van het configuratie-item en de CMDB.
• FIPS 199 (2004) voor de categorisering langs vertrouwelijkheid, integriteit en beschikbaarheid en voor het hoogste-waarde-principe, met de uitwerking in NIST SP 800-60.
• NIST SP 800-53 rev. 5, beheersmaatregel CM-8 over de inventaris van systeemcomponenten, die duidelijk laat zien dat de technische inventaris iets anders is dan de categorisering.
• NIST Cybersecurity Framework 2.0, categorie ID.AM, waarin het prioriteren van bedrijfsmiddelen op basis van classificatie en kritikaliteit expliciet is opgenomen.
• CIS Controls v8, beheersmaatregel 1 en 2 voor de inventaris van apparatuur en software, en beheersmaatregel 3.7 voor het gegevensclassificatieschema.

Onderzoeksliteratuur:

• Oppenheim, Stenson en Wilson, “The attributes of information as an asset” (New Library World, 2001) en de driedelige reeks “Studies on Information as an Asset” (Journal of Information Science, 2003–2004), over waarom informatie zich anders gedraagt dan een klassiek activum.
• Erik Bergström en collega's (Universiteit van Skövde en Jönköping University) over informatieclassificatie in de Zweedse publieke sector, onder meer “Developing an information classification method” (Information & Computer Security, 2021) en “An information classification model for public sector organizations in Sweden” (Information & Computer Security, 2022), met bevindingen over te complexe schema's, classificatie door de verkeerde functionaris en het ontbreken van een koppeling naar maatregelen.