Informatiebeveiliging en ICT-beheer op basis van ITIL

NB: 25 jaar geleden beschouwde men informatiebeveiliging als een ICT probleem en paste dit dus uitstekend in ITIL. Een moderne benadering van informatiebeveiliging is beschreven in ‘Pragmatische aanpak informatiebeveiliging‘. 

1. Beveiliging en beheer: ITIL Security Management 

Omdat bedrijven voor hun bedrijfsbelangen steeds meer afhankelijk worden van informatie en IT, wordt ook de beveiliging van de informatie en IT steeds belangrijker. In dit artikel wordt uitgelegd hoe beveiliging van, in en door de IT-infrastructuur wordt beheerd, vanuit de optiek van de aanbieder van IT-diensten, ofwel de service provider. 
De scope van dit artikel is het beheer van de IT-infrastructuur volgens ITIL. ITIL is een procesgerichte benadering voor IT-beheer. Het ITIL-proces Security Management geeft de structurele inpassing van beveiliging in de beheerorganisatie. ITIL Security Management is mede gebaseerd op de Code voor Informatiebeveiliging. 
De opbouw van dit artikel is als volgt. Eerst wordt ITIL kort besproken. Daarna wordt beschreven hoe de verschillende ITIL-processen moeten worden ingericht om beveiliging en het noodzakelijke beveiligingsbeheer mogelijk te maken. Tot slot wordt het proces Security Management zelf beschreven.  

2. ITIL en Informatiebeveiliging 

De afgelopen decennia is de complexiteit van de IT-infrastructuur belangrijk toegenomen. Juist vanwege die groeiende complexiteit is uniformiteit in het beheer noodzakelijk. ITIL staat voor Information Technology Infrastructrure Library. Het is een verzameling boeken waarin processen worden beschreven die uitgevoerd worden voor het beheer van de IT-infrastructuur. Security Management is één van de processen van ITIL. Het Security Management proces heeft veel relaties met andere processen, waarvan de belangrijkste in dit hoofdstuk worden beschreven. 

2.1 Opbouw ITIL en Security Management 

ITIL gaat uit van een procesmatige benadering van het beheer. Figuur 1 toont hier het model voor. In de processen komt het cyclische karakter van ‘management’ steeds naar voren: plan, implement, evaluate, maintain. In ITIL wordt het perspectief gekozen van de aanbieder van automatiseringsdiensten (de service provider). Deze biedt IT-diensten aan naar de wensen van zijn klanten. 
Ieder ITIL-proces bestaat met een doel. Dit doel wordt bereikt door het uitvoeren van een verzameling activiteiten. Deze activiteiten staan niet op zichzelf maar hangen met elkaar samen. Daarom spreken we van een proces. De trigger van het proces vormt de input, de resultaten van het proces de output. De samenhang met de andere processen wordt beschreven in de relaties. 

Voor het proces Security Management is dit model als volgt ingevuld: 
Het doel van dit proces is tweeledig: 

• Het realiseren van de beveiligingseisen in de verschillende Service Level Agreements (SLAs, de afspraken met de klant) en andere externe vereisten in andere contracten, wetgeving en eventueel intern of extern opgelegd beleid. 
• Het realiseren van een basisniveau aan beveiliging. Dit is nodig om de eigen continuïteit van de beheerorganisatie te waarborgen, maar ook om te komen tot vereenvoudiging van het Service Level Management voor informatiebeveiliging. Immers, het beheer van een groot aantal verschillende SLAs is veel complexer dan een beperkt aantal. 

De input-kant van het proces wordt gevormd door de bronnen die in het eerste deel van het doel worden genoemd. De output levert verantwoordingsinformatie op met betrekking tot de realisatie van de SLAs, inclusief een rapportage van afwijkingen. ITIL heeft in de laatste jaren een flinke verandering ondergaan. Terwijl het Security Management boek in april 1999 verscheen als laatste van de ongeveer 45 boeken, werd al gewerkt aan een revisie waarbij het aantal boeken werd teruggebracht naar zeven die verschenen tussen april 2000 en november 2002. De inhoud van de boeken is aangepast aan nieuwe inzichten. Het proces Security Management heeft relaties met de meeste andere ITIL-processen. In de andere ITIL-processen moeten namelijk activiteiten plaats vinden ten behoeve van beveiliging. Om deze relaties te begrijpen, wordt eerst de lagenstructuur van ITIL besproken. 

De driehoek in de figuur 2 toont de drie besturingslagen die in organisaties kunnen worden herkend. De ITIL processen zijn tot op zekere hoogte aan deze lagen toe te wijzen. In de bovenste laag wordt de strategie van het beheer uitgestippeld. Voor de informatiebeveiliging is deze vooral van belang waar het de organisatie van de beheerorganisatie betreft. Dit geldt overigens voor alle processen op dezelfde wijze. De Service Delivery processen zijn voornamelijk aan de middelste laag toe te wijzen. Hier bevinden zich processen die zorgen voor het opstellen van SLAs en die de dienstverlening verzorgen conform de afspraken in deze SLAs. Ook de beveiligingsafspraken worden vastgelegd in de SLAs. Het proces Security Management zelf bevindt zich ook in deze laag. Het proces Security Management heeft relaties met de andere Service Delivery processen: 

• Service Level Management; 
• Availability Management;
• Capacity Management;
• Business Continuity planning;
• Financial Management for IT. 

Dan is er tenslotte de operationele laag. Daarin zijn de Service Support processen te vinden. De Service Support processen verzorgen het daadwerkelijk operationeel beheer van de IT-middelen zelf. Het proces Security Management is afhankelijk van deze processen omdat deze voorwaardenscheppend zijn. Daarom heeft Security Management relaties met alle Service Support processen, te weten: 

• Configuration Management;
• Incident Management;
• Problem Management;
• Change Management en
• Release Management. 

Naast deze processen bevat het Service Support boek een beschrijving van de Service Desk als organisatorische eenheid waar onder meer het Incident Management wordt uitgevoerd. Ieder ITIL-proces heeft een verantwoordelijke manager. Bij Security Management wordt deze de Security Manager genoemd. In kleine beheerorganisaties kunnen meer processen door één functionaris worden gemanaged, terwijl in grote organisaties meer personen actief zijn in het security management. In het laatste geval is dan doorgaans wel één persoon als de Security Manager aangewezen. De tegenspeler aan de klantkant wordt de (Corporate) Information Security Officer genoemd. 

Het proces Security Management heeft, zoals gezegd, relaties met de bovengenoemde ITIL-processen, zie figuur 3. In deze processen moeten namelijk activiteiten plaats vinden ten behoeve van beveiliging. Deze activiteiten vinden op de gebruikelijke wijze plaats onder verantwoordelijkheid van het betreffende proces en de betreffende manager. Vanuit Security Management worden echter aanwijzingen gegeven aan deze processen met betrekking tot de inrichting van deze beveiligingsgerichte activiteiten. In praktijk komen afspraken in overleg tussen de Security Manager en de andere procesmanagers tot stand. 

2.2 De beveiligingsparagraaf in de Service Level Agreement 

In de Service Level Agreement (SLA) worden de afspraken met de klant vastgelegd. De SLA is de verantwoordelijkheid van het Service Level Management (SLM) en fungeert als belangrijkste sturingsinformatie voor de ITIL processen. Door middel van verantwoordingsinformatie wordt rekenschap gegeven over de prestaties van de beheerorganisatie ten opzichte van wat afgesproken is in de SLA. Naast de verantwoordingsinformatie die door de beheerorganisatie wordt aangeleverd, zal de klant doorgaans ook onafhankelijke informatie (laten) verwerven door een EDP-auditor. 

2.2.1 De beveiligingsparagraaf in de Service Level Agreement 

Figuur 5 toont hoe de beveiligingsparagraaf in de SLA tot stand komt. Allereerst dient de klant zelf te bepalen welke beveiligingsbehoefte hij heeft. De klant geeft uitdrukking aan de belangen van zijn bedrijfsprocessen. Deze bedrijfsprocessen zijn afhankelijk van de services van de IT en daarom van de IT-beheerorganisatie. Hoe de service-nemer zijn beveiligingsbehoefte (Service Level Requirements voor informatiebeveiliging) bepaalt, is geen onderdeel van ITIL. Doorgaans zal hij daar echter een vorm van risicoanalyse voor gebruiken. Zo’n analyse leidt tot de Service Level Requirements voor beveiliging (zie ook figuur 3). 

De vertegenwoordiger van de klant en de account manager van de service-aanbieder treden hierover in onderhandeling. De accountmanager zal naast de gestelde Service Level Requirements zijn standaard aanbod leggen, dat is vastgelegd in de Service Catalogus. In de Service Catalogus is ook het basisniveau voor beveiliging, ofwel de Security Baseline weergegeven. Dat zijn de beveiligingsmaatregelen die altijd worden geboden. Boven dit basisniveau kan de klant extra eisen stellen.

De klant en de accountmanager stellen samen vast hoe de Service Level Requirements en de Service Catalogus op elkaar passen. Een eerste aspect is daarbij dat sommige diensten afhankelijk zijn van derden. De service provider kan hier veelal niet de volledige verantwoordelijkheid voor nemen. Voorbeeld is de beschikbaarheid van telecommunicatieverbindingen, waarop leveranciers doorgaans geen garantie geven. De Service provider komt daarom met zijn klant overeen welke afspraken de provider maakt met zijn providers. Voorbeeld hiervan kunnen zijn: de contracten over de levering van huurlijnen, de contracten met hardware leveranciers met betrekking tot onderhoud en responsetijden. Deze overeenkomsten worden de Underpinning Contracts genoemd. Dat zijn afspraken waarvoor de service provider zelf geen volledige invloed uit kan oefenen op de realisatie van die afspraken. 

Het tweede aspect wordt gevormd door de Operational Level Agreements. Dat zijn de diensten die door de service provider zelf worden geleverd. Voor de service provider is het van belang dat hij intern verantwoordelijkheden verbindt aan deze agreements. De Service Catalogus is een algemene beschrijving van de diensten. De Operational Level Agreements, zijn de vertaling van deze algemene beschrijvingen naar alle services (Service Delivery) en de individuele componenten (zie de Configuration Items bij Configuration Management) alsmede de wijze waarop de afspraken over service levels intern zijn geborgd.  

3. Service Support processen 

De processen uit de Service Support Set richten zich op het beheer van de IT-middelen zelf. In deze paragraaf worden de processen uit deze set kort beschreven met de wijze waarop activiteiten binnen deze processen het proces Security Management dienen te ondersteunen. Zoals al eerder opgemerkt vindt overleg over deze voor beveiliging relevante activiteiten tussen de betreffende manager en de Security Manager. 

3.1 Configuration Management 

Een eerste vereiste voor goed IT-beheer is dat men het proces voor Configuration Management goed heeft opgezet. Configuration Management vormt de basis voor het beheer. Dit proces zorgt dat je weet wat er aan IT-infrastructuur in huis is, wat de status hiervan is, en welke relaties er zijn tussen de verschillende onderdelen van de infrastructuur (dus de relaties tussen de CI’s, zie later). Het proces heeft als doelstelling alle componenten van de IT-infrastructuur en de daaraan gerelateerde procedures en documentatie onder controle te brengen ter ondersteuning van de overige processen. 

Wanneer Configuratie Management goed is ingericht is het duidelijk uit welke configuratie-items de IT-infrastructuur bestaat, wie verantwoordelijk is voor welk item, waar de items zich bevinden en in welke toestand met welke relatie(s). Configuratie Management verstrekt informatie over de samenstelling van de IT-infrastructuur en is verantwoordelijk voor de correcte registratie van geautoriseerde onderdelen van de IT-infrastructuur. Bovendien verifieert Configuratie Management geregeld of de registratie nog een correcte afspiegeling vormt van de werkelijkheid. Op deze wijze wordt voorkomen dat met ongeautoriseerde onderdelen gewerkt wordt die niet aan de beveiligingseisen voldoen. 

Twee begrippen staan centraal: een configuration item (CI) is de kleinste eenheid die individueel wordt gemanaged. Het overzicht van alle CI’s vormt tevens het overzicht van de totale IT-infrastructuur. Dit overzicht is te vinden in de Configuration Management Database (CMDB). ITIL ziet als mogelijke Configuration Items: software (applicaties), hardware, netwerk, documentatie en procedures. 

3.1.1 Configuration Management en informatiebeveiliging 

Voor informatiebeveiliging is Configuration Management vooral van belang in verband met de mogelijkheid een rubricering (classificatie) aan een CI te geven. Deze rubricering koppelt de CI aan een bepaalde set beveiligingsmaatregelen of aan een procedure. 
Een classificatie of rubricering van een CI is een aanduiding van de gewenste vertrouwelijkheid, integriteit en/of beschikbaarheid van de CI. Deze classificatie wordt ontleend aan de beveiligingseisen uit de SLA. De ‘klant’ van de beheerorganisatie bepaalt de classificatie omdat hij als enige kan bepalen hoe belangrijk informatie of -systemen voor zijn bedrijfsprocessen zijn. De klant bepaalt de classificatie op basis van een analyse van de afhankelijkheid van zijn bedrijfsprocessen van de informatiesystemen en van de informatie zelf. Het is dan aan de beheerorganisatie deze classificatie te koppelen aan de juiste CI’s. De beheerorganisatie moet tevens per classificatieniveau een pakket beveiligingsmaatregelen implementeren dat voor dat niveau geldt. Deze maatregelen kunnen worden samengevat in een procedure. In de SLA kan worden vastgelegd welk pakket beveiligingsmaatregelen voor welk classificatieniveau moet worden geïmplementeerd. 
Een classificatiesysteem moet altijd op maat zijn voor de klantorganisatie. Voor de eenvoud van het beheer is het echter aan te raden één classificatiesysteem na te streven, ook indien een beheerorganisatie meerdere klanten heeft. 

3.2 Incident Management en Service Desk 

In het huidige Service Support boek wordt onderscheid gemaakt tussen Incident Management als proces en de Service Desk als organisatorische eenheid waar veel activiteiten van dit proces zijn belegd. De voornaamste doelstelling van Incident Management is de continuïteit van de dienstverlening voor de klanten. 

Activiteiten van het proces Incident Management zijn het administreren, volgen en beheersen van incidenten. Dit proces is het centrale proces waar de registratie en bewaking van alle incidenten plaatsvindt. De Service Desk fungeert als één loket voor alle incidentmeldingen en eerste lijn’s hulp. Incident Management is de ‘eigenaar’ van alle incidenten. 
Incident Management registreert incidenten en ziet er op toe dat deze zo snel mogelijk worden opgelost. Dit geldt ook voor incidenten die betrekking hebben op beveiliging. 

De input voor Incident Management bestaat grotendeels uit meldingen van gebruikers. Voor iedere melding wordt een incident gedefinieerd. Incidenten worden gecategoriseerd en per categorie is een procedure gedefinieerd die voorschrijft welke activiteiten moeten worden ondernomen door Incident Management. Een juiste categorisering is van groot belang voor beveiliging. Veelal wordt gewerkt met een aanduiding van het effect (impact) van een incident. Indien het effect is dat het halen van de SLA direct in gevaar komt, dan heeft dat een hogere prioriteit. Bij het registreren van een incident wordt zo mogelijk een koppeling gemaakt met de CI waar het incident betrekking op heeft. 

De output bestaat, zoals gezegd, uit directe oplossingen of alternatieve werkwijzen. In alle gevallen vindt registratie van incidenten plaats, deze vormen de input voor het proces Problem Management. 

3.2.1 Incident Management en informatiebeveiliging 

Incident Management is het centrale proces voor het melden van beveiligingsincidenten. Voor beveiligingsincidenten kan, afhankelijk van de ernst van het incident, een andere procedure gelden dan voor gewone incidenten. Het is dus van groot belang dat Incident Management een beveiligingsincident als zodanig herkent. Beveiligingsincidenten zijn sowieso al die incidenten die het halen van de beveiligingseisen uit de SLA kunnen verhinderen. Het is nuttig in de SLA een overzicht op te nemen van het soort incidenten dat als beveiligingsincident moet worden beschouwd. Ook incidenten die het halen van het eigen beveiligingsbasisniveau (baseline) verhinderen, worden aangemerkt als beveiligingsincidenten. 
Het is aan te raden de procedure rond verschillende soorten beveiligingsincidenten in de SLA vast te leggen en deze procedure ook te oefenen. Het is ook aan te raden een procedure af te spreken omtrent de communicatie rond beveiligingsincidenten. Het is niet de eerste keer dat een organisatie in paniek raakt vanwege een opgeblazen gerucht. Het is ook niet de eerste keer dat onnodige schade ontstaat doordat niet tijdig wordt gecommuniceerd over een beveiligingsincident. Het is verstandig alle externe communicatie met betrekking tot beveiligingsincidenten via de Security Manager of de Security Officer te laten verlopen. 

3.3 Problem Management 

Het proces Problem Management heeft als doel de incidenten van het proces Incident Management te onderzoeken, verbanden te leggen en te komen met structurele oplossingen. Wanneer de oorzaak van een probleem is vastgesteld, dan wordt een onderkende fout (known error) gedefinieerd. De input voor dit proces bestaat voornamelijk uit incidenten. De output van het proces Problem Management bestaat uit voorlopige oplossingen, onderkende fouten (known errors) en Request For Changes (RFC’s). Een RFC is een voorstel voor een wijziging (change) in de IT-infrastructuur. 
De voorlopige oplossingen worden gedocumenteerd en toegankelijk gemaakt voor de Service Desk. Ofwel, van incident tot leermoment. De Known errors en de RFC’s vormen de input voor het proces Change Management. 

3.3.1 Problem Management en informatiebeveiliging 

Als een ‘problem’ uit een beveiligingsincident voortkomt, kan het zijn dat daar een aparte procedure voor wordt gevolgd. Een aantal zaken is in het bijzonder van belang. Denk allereerst na over de mensen die betrokken mogen zijn of kennis mogen hebben van het incident. Dit omdat het wenselijk is de groep mensen met kennis van het incident zo beperkt mogelijk te houden (misschien is een van de eigen medewerkers wel degene die het beveiliginsincident heeft veroorzaakt). Maar ook omdat de kennis over een mogelijk lek in de beveiliging tot een zo klein mogelijke groep beperkt blijft, vanuit het oogpunt van misbruik en exploitatie van dat lek. Denk ook na over de mensen die juist betrokken moeten zijn bij het onderzoeken van de oorzaken van zo’n incident (de Security Manager van de beheersorganisatie, wellicht zelfs de Security Officer van de klant). En ten slotte, toets bij het voorbereiden van een oplossing altijd of door deze oplossing geen nieuwe beveiligingsproblemen ontstaan (toets aan het halen van de SLA en de eigen baseline). 

3.4 Proces Change Management 

Het proces Change Management heeft als doel alle wijzigingen op of van CI’s te beheersen en te beheren. Wijzigingen in de IT-infrastructuur komen altijd tot stand via dit proces. Een Change is een gecontroleerde wijziging in de IT-infrastructuur. Input voor Change Management vormen de Requests For Change (RFC’s). 
De Change Manager beslist over het al dan niet accepteren van een RFC. Daarbij kan hij zich door de Change Advisory Board (CAB) laten adviseren voordat het wijzigingsvoorstel wordt geautoriseerd. 
Onderdeel van de activiteiten is het opstellen, behandelen, doen verwerken en, na accordering, doen implementeren van een Change. De output van dit proces is een geëvalueerde en geautoriseerde Change. Onderdeel van het uitvoeren van de Change zelf is het bijwerken van de gegevens over de betrokken CI(‘s) in de CMDB door het proces Configuration Management. 

3.4.1 Change Management en informatiebeveiliging 

De activiteiten binnen het proces Change Management zijn veelal sterk gerelateerd aan beveiliging. Indien een situatie is bereikt met een acceptabel beveiligingsniveau, en het wijzigingsproces beheerst deze situatie, dan kan men zelf in de hand houden dat de nieuwe situatie ook een acceptabel beveiligingsniveau heeft. Daarom wordt een aantal vaste stappen onderscheiden om dit beveiligingsniveau zo goed mogelijk te waarborgen. Figuur 6 toont de stappen die moeten worden doorlopen. Input is een RFC waarin het voorstel tot wijziging van de IT-infrastructuur met onderbouwing en referentie van de betrokken CI’s is opgenomen. Aan een RFC worden parameters gekoppeld die de procedure voor acceptatie beïnvloeden. De parameters in de figuur zijn als voorbeeld bedoeld, andere keuzes zijn mogelijk. Hier is gekozen voor parameters voor urgentie en impact. Daar is de parameter ‘invloed op informatiebeveiliging’ aan toegevoegd. Indien het voorstel een grote invloed op de informatiebeveiliging kan hebben, dan zijn bijvoorbeeld zwaardere acceptatietesten en -procedures noodzakelijk. 
Onderdeel van de RFC vormt ook het voorstel omtrent de invulling van de beveiliging. Hierbij geldt als uitgangspunt wederom dat wat is afgesproken in de SLA alsmede dat wat de beheerorganisatie zelf als basisniveau heeft gekozen. Dit voorstel voor de invulling van de beveiliging bestaat dus uit een verzameling beveiligingsmaatregelen. Deze maatregelen worden ontleend aan de Code voor Informatiebeveiliging. 

Vervolgens wordt de RFC beoordeeld en geautoriseerd. Voor RFC’s met een beperkte invloed kan dat door de Change Manager zelf geschieden. Voor een zware RFC vindt de beslissing plaats op basis van raadpleging van de Change Advisory Board (CAB). In de CAB neemt in ieder geval de Security Manager plaats, en mogelijk ook de security officer (beveiligingsfunctionaris) van de klant(-en) indien de RFC een grote mogelijke invloed op de beveiliging heeft. 
Het is overigens niet de bedoeling de Security Manager voor iedere Change in te schakelen. Beveiliging dient zoveel mogelijk een geïntegreerd onderdeel te zijn van de normale taken. De Change Manager moet in staat zijn te beoordelen of hij, danwel de CAB, de input van de Security Manager nodig heeft. Ook voor de selectie van maatregelen voor de CI’s die in de RFC betrokken zijn, is de Security Manager niet persé noodzakelijk. Immers, als het goed is staat het raamwerk voor de te treffen maatregelen al klaar en is alleen nog de vraag op welke wijze deze moeten worden geïmplementeerd. 

3.5 Release Management 

Het laatste Service Support proces dat hier wordt besproken is het proces Release Management. Het doel van dit proces is het versiebeheer van de software te implementeren en de uitrol van de software en hardware te verzorgen. Input voor dit proces is een geautoriseerde RFC van het proces Change Management. Dit proces beschikt hiertoe over wat genoemd wordt de ‘definitive software library’. Dat is een bibliotheek van alle juiste, erkende en geautoriseerde software en bevat indien aanwezig de broncode en daarnaast de installatiebestanden van gekochte software. Terwijl de CMDB de beschrijving en samenhang van de software bevat, is de daadwerkelijke software te vinden in de DSL. 

3.5.1 Release Management en informatiebeveiliging 

Van belang is dat alle software en hardware via dit proces op beheerste wijze de organisatie binnenkomt. Dit proces zorgt er voor: 

• dat de juiste hardware en software wordt gebruikt; 
• dat deze vooraf getest is; 
• dat de introductie op de juiste wijze (door een Change) geautoriseerd is; 
• dat de software legaal is;
• dat de software virusvrij is en ook virusvrij wordt verspreid,
• dat de versienummers bekend zijn (en geregistreerd door Configuration Management in de CMDB);
• dat beheerste invoering plaatsvindt. 

Ook dit proces werkt volgens een vaste acceptatieprocedure. In deze acceptatieprocedure dient informatiebeveiliging de nodige aandacht te krijgen. Met name is van belang dat tijdens het testen en de acceptatie de implicaties voor de beveiliging worden meegenomen. Dit betekent dat blijvend aan de in de SLA afgesproken beveiligingseisen en maatregelen moet worden voldaan. 

4. De Service Delivery processen en informatiebeveiliging 

De Service Delivery processen zijn nauw verwant aan beveiliging. Bij de herstructurering van ITIL is overwogen ook Security Management op te nemen binnen het nieuwe Service Delivery boek. Dat het toch in een apart boek is ondergebracht, komt meer omdat dit boek pas zo kort voor de ITIL revisie is gepubliceerd dan door inhoudelijke redenen. 

Hieronder volgt een korte samenvatting van de relaties met de Service Delivery processen. 

4.1 Service Level Management 

Service Level Management zorgt er voor dat afspraken worden vastgelegd en nagekomen over de diensten die aan klanten worden geleverd. In deze Service Level Agreements dienen tevens afspraken te worden gemaakt over de te nemen beveiligingsmaatregelen. Het doel is te komen tot een optimaal niveau van IT-dienstverlening. 

Service Level Management onderscheidt een aantal samenhangende beveiligingsactiviteiten waarin Security Management een belangrijke rol speelt: 

1. dentificatie van de beveiligingsbehoefte van de klant (het vaststellen van de beveiligingsbehoefte blijft uiteraard de verantwoordelijkheid van de klant zelf omdat deze behoefte voortkomt uit zijn bedrijfsbelangen); 

2. verifiëren van de haalbaarheid van deze beveiligingsbehoefte van de klant; 

3. voorstellen doen voor, onderhandelen over en vastleggen van het gewenste beveiligingsniveau van de IT-diensten in de SLA; 

4. doen bepalen, opstellen en vastleggen van interne beveiligingsnormen voor de IT-dienstverlening; 

5. doen bewaken van die beveiligingsnormen; 

6. rapporteren over geleverde IT-diensten. 

Voor de eerste drie activiteiten levert Security Management input en ondersteuning aan Service Level Management. Activiteiten vier en vijf worden uitgevoerd door Security Management. Voor activiteit zes levert onder ander Security Management input. De daadwerkelijke uitvoering van de activiteiten (wie doet wat) is een kwestie van overleg tussen de Service Level Manager en de Security Manager. 
Bij het vaststellen van het SLA is veelal uitgangspunt dat er een algemeen niveau van beveiliging bestaat (het basisbeveiligingsniveau, of baseline). Wanneer een klant een betere beveiliging wenst, dan wordt dit expliciet in de SLA te vastgelegd. 

4.2 Availability Management 

Availability Management houdt zich bezig met de technische beschikbaarheid van IT-componenten. Het kwaliteitsaspect beschikbaarheid wordt geborgd door betrouwbaarheid, onderhoudbaarheid en veerkracht. De betrouwbaarheid van een IT-dienst geeft aan in welke mate de dienst de afgesproken functionaliteit biedt gedurende een aangegeven tijdsduur. Onderhoudbaarheid is een indicatie voor het gemak waarmee onderhoud aan een dienst gedaan kan worden. Veerkracht is het vermogen van een IT-dienst om op de juiste wijze te blijven functioneren ondanks het niet goed functioneren van één of meerdere subsystemen. 
Availability Management heeft een dominante rol in de realisatie van het aspect ‘beschikbaarheid’. In de ITIL-definitie van beveiliging valt beschikbaarheid dan ook niet onder het proces Security Management. Dit lijkt echter meer een historisch feit dan een bewuste keuze te zijn. 

Aangezien vele beveiligingsmaatregelen zowel ten goede kunnen komen van beschikbaarheid als van de beveiligingsaspecten vertrouwelijkheid en integriteit, is afstemming over de te treffen maatregelen tussen Availability Management en Security Management noodzakelijk. Ook IT Service Continuity Management maatregelen dienen in dit verband te worden beschouwd. 

4.3 Capacity Management 

Capacity Management is verantwoordelijk voor de optimale inzet van IT-middelen zoals die met de opdrachtgever is overeengekomen. Binnen Capacity management worden drie subprocessen onderscheiden: 

• Business Capacity Management richt zich op trendanalyse, voorspellen, modelleren, sizing en documenteren van de toekomstige klantbehoeften; 
• Service Capacity Management op het bewaken, analyseren, tunen en rapporteren over prestaties van diensten, het vastleggen van wat normale belastingen zijn voor diensten en het bijstellen van de vraag; 
• Resource Capacity Management richt zich op het bewaken, analyseren, tunen en rapporteren over belastingen van componenten en het vastleggen van was normale belastingen zijn voor componenten. 

Met name het eerstgenoemde deelproces, Business Capacity Management, heeft een nauwe relatie het proces Service Level Management. 
Veel van de activiteiten binnen het proces Capacity Management hebben een relatie met het aspect beschikbaarheid.Capacity Management heeft dan ook in eerste instantie een relatie met Availability Management, en daardoor ook met Security Management. 

4.4 IT Service Continuity Management 

IT Service Continuity Management zorgt er voor dat, wanneer zich een calamiteit heeft voorgedaan, de gevolgen hiervan voor de IT-dienstverlening beperkt blijven tot een met de klant overeengekomen niveau. Een van de belangrijkste activiteiten is het opstellen, onderhouden, implementeren en testen van het uitwijkplan. Er zijn om verschillende redenen banden met Security Management. Enerzijds vanwege de beveiligingsaspecten van dit onderwerp, maar ook omdat een calamiteit gezien kan worden als een extreme vorm van onbeschikbaarheid en omdat beveiligingsmaatregelen calamiteiten kunnen voorkomen. 

4.5 Financial Management for IT 

Financial Management for IT heeft tot doel om inzicht te hebben in de kosten, kosten te bewaken en door te belasten aan de klanten van IT diensten. 
Financial Management geeft inzicht in een deel van de kosten van beveiligingsmaatregelen. Niet alle kosten zijn als zodanig zichtbaar, omdat zij vaak verborgen zijn of direct gerelateerd zijn aan het managen van de algemene IT infrastructuur. 

5. Het proces Security Management 

In het vorige hoofdstuk zijn de relaties van Security Management met de andere processen aangegeven. In dit hoofdstuk komen de activiteiten naar voren die ofwel door Security Management zelf worden uitgevoerd, ofwel waarvoor Security Management de aansturing verzorgt ten behoeve van de implementatie binnen een ander proces. 
De figuur toont de managementcyclus voor Security Management. De eisen van de klant vormen de invoer voor het proces. Deze eisen worden vertaald in de te leveren beveiligingsdiensten en -kwaliteit in de beveiligingsparagraaf van de Service Level Agreement (SLA). De service provider detaileert deze afspraken naar zijn organisatie in de vorm van een beveiligingsplan (waarin de beveiligingsnormen zijn vastgelegd). Dat plan wordt geïmplementeerd en deze implementatie wordt geëvalueerd. Indien nodig vindt onderhoud plaats op zowel het plan als de implementatie daarvan. Over de activiteiten wordt gerapporteerd aan de klant. De cyclus sluit hier zowel bij de klant als bij de provider. Ten eerste kan de klant op basis van deze rapportages zijn eisen en wensen aanpassen. Ten tweede kan de service provider op basis van zijn bevindingen zijn plan of de implementatie bijstellen, danwel aansturen op aanpassing van de afspraken in de SLA. In het midden is de ‘sturing’ zelf aangegeven. 

5.1 Sturing – beleid en organisatie van de informatiebeveiliging 

De activiteit ‘sturing’, in het midden van de figuur, is het eerste subproces binnen het proces Security Management. ‘Sturing’ organiseert en beheerst het proces Security Management zelf. Dit omvat de organisatie van het beheerraamwerk voor informatiebeveiliging. Dit raamwerk definieert de subprocessen: hoe beveiligingsplannen tot stand komen, hoe deze worden geïmplementeerd, hoe de implementatie wordt geëvalueerd en hoe de resultaten van deze evaluaties vervolgens weer worden vertaald in de beveiligingsjaarplannen (de actieplannen). Tevens wordt gedefinieerd hoe de rapportage aan de klant plaatsvindt (via SLM). 

‘Sturing’ definieert de subprocessen, de beveiligingsfuncties, de rollen en de verantwoordelijkheden. Tevens wordt de organisatiestructuur beschreven alsmede de rapportagelijnen en de ‘bevels’-lijnen (wie geeft opdrachten aan wie; wie voert uit; hoe wordt gerapporteerd over de uitvoering). 

Ook in de andere ITIL-processen is een subproces ‘sturing’ aanwezig. Deze sturingsactiviteiten hangen met elkaar samen. Daartoe is het managen van de processen onderling georganiseerd. 
Binnen het subproces ‘sturing’ worden maatregelen uit de Code voor Informatiebeveiliging worden geïmplementeerd op het gebied van Beleid en Organisatie van de informatiebeveiliging. 

5.2 Plan 

Het subproces ‘Plan’ omvat onder meer de activiteiten die leiden tot de beveiligingsparagraaf in de SLA (in samenwerking met Service Level Management), alsmede de activiteiten in relatie tot de underpinning contracts (voor zover specifiek voor beveiliging). De algemeen geformuleerde doelstellingen in de SLA worden verfijnd en nader gespecificeerd binnen de Operational Level Agreements. Deze OLAs vormen daarmee de basis voor de beveiligingsplannen per organisatie-eenheid binnen de organisatie van de service provider en voor de specifieke beveiligingplannen, bijvoorbeeld per specifiek IT-platform, per specifieke applicatie en per netwerk. 

Naast de input van de SLA, werkt het subproces ‘Plan’ ook met beleidsuitgangspunten van de service provider zelf (uit het subproces ‘Sturing’). Voorbeelden van beleiduitgangspunten kunnen zijn: “Iedere gebruiker moet uniek identificeerbaar zijn”, of “een basisniveau aan beveiliging wordt altijd geboden en aan alle klanten”. 

De Operational Level Agreements voor informatiebeveiliging (de specifieke beveiligingsplannen) worden opgesteld en geïmplementeerd volgens de normale route. Dat betekent dat indien activiteiten binnen andere processen zijn gewenst, afstemming met deze processen plaatsvindt. Indien wijzigingen in de IT-infrastructuur gewenst zijn, dan komen deze alleen tot stand via het Change Management proces. Security Management levert hiervoor de input. De Change Manager is verantwoordelijk voor het Change Management proces zelf. Dit subproces wordt afgestemd met het proces Service Level Management. Dit in verband met het opstellen van, het onderhouden van, en het voldoen aan de beveiligingsparagraaf van de SLA. De Service Level Manager is voor deze afstemming verantwoordelijk. 

In de SLA dienen de beveiligingseisen te worden gespecificeerd, voor zover mogelijk in meetbare termen. Een SLA is een formeel contract tussen de klant (een bedrijf) en de IT service provider. In de beveiligingsparagraaf dient te worden zekergesteld dat aan alle beveiligingseisen en -normen van de klant op een controleerbare wijze kan worden voldaan. Overigens wordt in het boek ITIL Security Management uitgebreid ingegaan op aandachtspunten voor de beveiligingsparagraaf in de SLA en de wijze waarop SLAs en OLAs tot stand komen. 

5.3 Implementatie 

Het subproces ‘implementatie’ zorgt er voor dat alle maatregelen zoals gespecificeerd in de plannen worden geïmplementeerd. Merk op dat binnen dit proces geen maatregelen worden gedefinieerd of gewijzigd. Dat vindt plaats via het proces Change Management, in afstemming met het subproces ‘Plan’. Hierbij gaat het om maatregelen uit de volgende categorieën: 

• Classificatie en beheersing van IT-hulpmiddelen;
• Personele beveiliging;
• Veilig beheer;
• Toegangsbeveiliging. 

5.4 Audit en evaluatie 

Onafhankelijke evaluatie van de implementatie van de geplande maatregelen is essentieel. Deze evaluatie is noodzakelijk om het eigen functioneren te bewaken. Deze evaluatie is ook noodzakelijk voor de klanten en eventuele derde partijen. De resultaten van het subproces ‘evaluatie’ worden gebruikt voor het onderhouden van de afgesproken maatregelen (in afstemming met de klant) en de implementatie zelf. Evaluatieresultaten kunnen aanleiding geven tot wijzigingen. Dan wordt een Request for Change (RFC) gedefinieerd en aangeboden aan het Change Management proces. 

Drie soorten evaluaties worden onderscheiden: 

• Self assessments (uitgevoerd door de lijnorganisatie van de processen). 
• Interne audits (uitgevoerd door interne EDP auditors); 
• Externe audits (externe, nog meer onafhankelijke EDP auditors); 

Audits worden niet uitgevoerd door dezelfde medewerkers als in de andere subprocessen. Dit in verband met de noodzakelijke functiescheiding. Mogelijk worden voor audits medewerkers van de afdeling Interne Controle ingezet. 
Verder vindt uiteraard evaluatie plaats op basis van de gemelde beveiligingsincidenten. 
De belangrijkste activiteiten zijn: 

• Verifiëren van de naleving van beveiligingsbeleid en implementatie van beveiligingsplannen; 
• Beveiligingscontrole op IT-systemen; 
• Opsporen en reageren op ongewenst gebruik van IT-voorzieningen; 
• Uitvoeren van EDP-audits voor het aspect informatiebeveiliging. 

5.5 Onderhoud 

Onderhoud aan beveiliging is noodzakelijk. Dit omdat de risico’s veranderen door veranderingen in de IT-infrastructuur, de organisatie en de bedrijfsprocessen. Het onderhoud aan de beveiliging betreft zowel het onderhoud aan de beveiligingsparagraaf van de SLA als aan de gedetailleerde beveiligingsplannen binnen de Operational Level Agreements. 
Het onderhoud is gebaseerd op de resultaten van het evaluatie-subproces en inzicht in wijzigende risico’s. Deze activiteit levert alleen voorstellen op. Deze voorstellen worden ofwel ingevoerd in het subproces ‘plan’, ofwel worden meegenomen in het onderhoud van de SLA als geheel. In beide gevallen kunnen de voorstellen leiden tot opname van activiteiten in het beveiligingsjaarplan (actieplan). Wijzigingen volgen het normale Change Management proces. 

5.6 Rapportage 

Rapportage is een resultaat van andere subprocessen. Dit vindt plaats om verantwoording af te leggen over de geleverde beveiligingsdiensten, om relevante informatie te verstrekken over beveiliging aan de klanten, maar ook omdat rapportage veelal expliciet wordt afgesproken. 

Rapportage is van groot belang, ook voor de service provider. De klant moet een correct beeld krijgen van de efficiëntie van de inspanningen (bijvoorbeeld met betrekking tot realisatie van de beveiligingsmaatregelen) en van de beveiligingsmaatregelen zelf. Ook krijgt de klant een rapportage over de beveiligingsincidenten. 
De rapportages gaan in ieder geval over de volgende onderwerpen: 

• De mate waarin wordt voldaan in de afgesproken criteria in de SLA; 
• Opgetreden beveiligingsincidenten en de wijze van afhandelen daarvan. 

Normaal vinden rapportages plaats via Service Level Mangement. Er kan een uitzondering gemaakt worden voor bepaalde beveiligingsincidenten, waarbij een rechtstreeks communicatiekanaal wordt geopend de Corporate Information Security Officer. 

6. Tot slot: ITIL en beveiliging, samen een beheerst proces 

Beveiliging en beheer zijn twee begrippen die zeer dicht bij elkaar staan. De een kan niet zonder de ander. Beveiliging is afhankelijk van beheer, en beheer kan niet zonder goede beveiliging. 

Figuur 8 toont in de top een relatief groot aantal incidenten, waarbij de beveiligingsincidenten moeten worden herkend door Incident Management. Op ernstige incidenten is een passende reactie nodig. Daarnaast ontstaat inzicht in de effectiviteit van de beveiligingsmaatregelen op basis van een totaaloverzicht van alle beveiligingsincidenten. Problem Management analyseert de oorzaken van beveiligingsincidenten en doet in een RFC voorstellen om de incidenten voor de toekomst te voorkomen. Vervolgens volgt het Change Management proces dat op basis van wijzigingsvoorstellen (RFC’s) op beheerste wijze aanpassingen verzorgt in de IT-infrastructuur. Onderdeel van deze beheersing is dat tevens de noodzakelijke beveiligingsmaatregelen worden getroffen. De organisatie van de beveiligingsactiviteiten is de verantwoordelijkheid van Security Management. 
Omdat met het gebruik van ITIL een beheerst proces ontstaat, zullen ook minder fouten in beheer en beveiliging ontstaan. En dat is een groot winstpunt voor beveiliging. 

Delen van dit artikel zijn overgenomen uit: J.van Bon, ‘IT-service management, een introductie’. Van Haren Publishing. 2002.