EEN GENERIEK MODEL VOOR EEN IN-CONTROL STATEMENT BIJ KEY MANAGEMENT

EEN GENERIEK MODEL VOOR EEN IN-CONTROL STATEMENT BIJ KEY MANAGEMENT

Versie: 1.6 Datum: 19 mei 2007

De sleutel tot succes?

Voorwoord Ter afsluiting van onze studie EDP-audit aan de vrije Universiteit amsterdam hebben wij een scriptie geschreven over de vraag of er een generiek model is om het key management proces uiteindelijk “in control’ te verklaren. Key management is het proces dat cryptografie ondersteunt, die op haar beurt de bedrijfsdoelstellingen binnen de Rabobank ondersteunt. Vanuit de vrije Universiteit amsterdam is de heer Bart Bokhorst aangewezen als externe scriptiebegeleider. De gesprekken met Bart hebben tot interessante discussies geleid en ons uiteindelijk in de juiste richting gestuurd. We zijn hem dan ook zeer erkentelijk voor zijn kritische doch waardevolle opmerkingen waardoor we steeds een stap voorwaarts hebben kunnen maken. Naast Bart heeft Paul Samwel als interne scriptiebegeleider gefungeerd. Ook de gesprekken met Paul hebben geleid tot meer doordachte keuzes en waren daardoor van toegevoegde waarde voor de scriptie. We willen Paul hiervoor dan ook hartelijk danken. Buiten de scriptiebegeleiders zijn er nog diverse ander personen geweest die we dank verschuldigd zijn: naast de personen die vermeld staan in de lijst van geïnterviewden, is dat niet op de laatste plaats het thuisfront. Ronald van Erven Arie Schilp

Teamnummer Auteur(s) Datum Versie

719 A. Schilp & R. van Erven 19 mei 2007 1.6 Een generiek model voor ICS bij KM

Pagina 1 van 32

Inhoudsopgave VOORWOORD .......................................................................................................................... 1 MANAGEMENT SAMENVATTING........................................................................................... 3 1

INLEIDING ......................................................................................................................... 5 1.1 1.2 1.3

AANLEIDING .................................................................................................................. 5 TOELICHTING OMGEVING EN PROBLEMATIEK.................................................................... 6 AFBAKENING EN PROBLEEMSTELLING ............................................................................. 7

1.3.1

1.4 1.5 1.6 2

Subvragen......................................................................................................................... 7

ONDERZOEKSMODEL ..................................................................................................... 8 GEGEVENS.................................................................................................................... 9 LEESWIJZER .................................................................................................................. 9

UITWERKING PROBLEEMSTELLING........................................................................... 10 2.1

IN CONTROL ................................................................................................................ 10

2.1.1 2.1.2 2.1.3

2.2

Definitie In control ...........................................................................................................12 In-control statement ........................................................................................................ 12 Eisen aan een “in-control statement” (ICS) ..................................................................... 12

CRYPTOGRAFIE ........................................................................................................... 14

2.2.1 2.2.2

2.3

Wat is cryptografie .......................................................................................................... 14 Vormen van cryptografie ................................................................................................. 15

KEY MANAGEMENT....................................................................................................... 17

2.3.1

3

BEHEERSPROCESSEN ................................................................................................. 20 3.1

4

STANDAARD BEHEERSPROCESSEN (ITIL)...................................................................... 20

MODELLERING ............................................................................................................... 21 4.1

5

Key management als een proces.................................................................................... 17

PROTOTYPEMODEL ...................................................................................................... 21

GENERIEK MODEL......................................................................................................... 23 Configuration Management (ITIL – Service Support) ...................................................................... 23 Incident Management (ITIL – Service Support)............................................................................... 24 Problem Management (ITIL – Service Support).............................................................................. 24 Change Management (ITIL – Service Support)............................................................................... 24 Release Management (ITIL – Service Support) .............................................................................. 25 Availability Management (ITIL – Service Delivery) .......................................................................... 25 Service Level Management (ITIL – Service Delivery) ..................................................................... 26

6

CONCLUSIE .................................................................................................................... 27

BIJLAGE A. AFKORTINGEN & DEFINITIES ........................................................................ 29 BIJLAGE B. LITERATUURLIJST........................................................................................... 30 BIJLAGE C. GEÏNTERVIEWDEN........................................................................................... 31



Pagina 2 van 32

Management samenvatting Beursgenoteerde ondernemingen, en banken in het bijzonder, hebben de afgelopen jaren met steeds meer weten regelgeving te maken gekregen. De mogelijke sancties, zoals strafrechtelijke vervolging, waarschuwingen en boetes of het verplicht reserveren van (extra) kapitaal, maken dat er meer noodzaak is om aan te tonen dat ze processen (voldoende) beheersen. Hierbij is een verschuiving waar te nemen van generieke naar specifieke processen. Met een ‘In-Control Statement’ in het jaarverslag of een rapportage standaard, geeft de organisatie aan de processen voldoende te beheersen. Zo worden processen ondersteund door ICT-diensten. In het geval van betalingsverkeer wordt er gebruikgemaakt van cryptografische diensten. Deze diensten zijn nodig om aan de kwaliteitseisen van het betalingsverkeerproces te voldoen. Afhankelijk van de cryptografische In Control en In Bedrijfsdoelstellingen Eisen toepassing kunnen vertrouwelijkheid, Control Statement integriteit, authenticiteit en onweerlegbaarheid in het Primaire betalingsverkeerproces gewaarborgd bedrijfsprocessen worden. om doelstellingen te behalen

Een cryptografische dienst steunt volledig op sleutels. De sleutels zijn het geheim op basis waarvan vertrouwelijke informatie wordt uitgewisseld en vormen hierdoor een belangrijk element. De sleutels hebben een bepaalde levensloop vanaf generatie tot en met vernietiging. Het beheer van de sleutels tijdens deze levensloop, het key management, is een voorwaarde voor succes. Daarom zullen alle processen rondom het key management aantoonbaar beheerst moeten worden.

Generiek beheerproces Informatie in processen

Kwaliteitseisen Control Objectives Maatregel: cryptografie

Key Management

Toetsing

Zo wordt er binnen de Rabobank gebruikgemaakt van een groot aantal In Control Statement cryptografische methodieken ter ondersteuning van het betalingsverkeer. Bij dit proces zijn verschillende partijen betrokken voor datapreparatie, (betaal)pas aanmaken Figuur1: proces overzicht en afhandeling van de geldtransacties die daarmee verricht wordt. Voor dit laatste is een scala van gelduitgevende of -innemende apparatuur aanwezig. Hierop worden initieel en periodiek verschillende sleutels geladen. Door de diversiteit van producten en apparaten binnen de verschillende productgroepen van de bank, is het bijbehorende key management in de loop der tijd door verschillende afdelingen uitgevoerd of uitbesteed. Diverse reorganisaties van de afgelopen jaren hebben bijgedragen aan deze versnippering. De uitstroom van medewerkers met deze specialistische kennis heeft tot gevolg dat key management op dit moment onvoldoende aandacht krijgt en waarschijnlijk onvoldoende beheerst wordt.



Pagina 3 van 32

Door de toegenomen complexiteit en veelvoud van apparaten en technieken is het onmogelijk key management niet specifiek te behandelen (‘er even bij te doen’). Deze problematiek willen we oplossen door key management centraal in te richten inclusief bijbehorende processen. Omdat we een sleutel zien als een asset, hebben we onderzocht of we deze processen kunnen koppelen aan ITIL. Deze best practice heeft als voordeel dat de organisatie hier al mee werkt en dus geen separate introductie behoeft. Een potentieel gevaar van ITIL is echter de massaliteit. Er zijn vele processen die ingericht kunnen worden. Omwille van de pragmatische insteek hebben we daarom keuzes gemaakt voor de ITIL-processen waarmee key management voldoende ondersteund kan worden. Centraal hierbij staat de Configuration Management Data Base, waarin alle meta-informatie van sleutels vastgelegd wordt en die input is voor de overige processen Change Management, Problem Management, Incident Management, Availability Management, Release Management en Service-Level Management. Om de hierboven beschreven complexe omgeving te onderzoeken is onze onderzoeksvraag: “Is het mogelijk om een generiek model te definiëren waarmee een ‘in-control statement’ voor het proces ’key management (KM)’ kan worden afgegeven? “ Tijdens ons onderzoek hiernaar hebben we de key life cycle in relatie tot de ITIL-processen uitgezet. Hierbij is gekeken welke ITIL-processen een toegevoegde waarde kunnen hebben tot de verschillende fases in de key life cycle. De aanvulling van het ene generieke model met het andere generieke model levert voldoende synergie op om dit als nieuw generiek model te kwalificeren. Wij zijn van mening dat we de onderzoeksvraag hiermee positief kunnen beantwoorden. Met het nieuwe model is het key management proces concreter meetbaar voor auditors. Zij kunnen hierdoor aan het management en de directie een ‘in-control statement’ afgeven omtrent het beheer van de cryptografische diensten.



Pagina 4 van 32

1 Inleiding Ter ondersteuning van bedrijfsprocessen en bedrijfsvoering maakt de Rabobank gebruik van ICT-diensten en ICT-dienstverleners, en ook van cryptografische diensten om zo te voldoen aan de, door commerciële afdeling en directie gestelde kwaliteitseisen met betrekking tot de betrouwbaarheid en vertrouwelijkheid van het data- en transactieverkeer van betalingssystemen. Omdat het beheer van ICT-diensten veelal over meerdere interne afdelingen gaat en zelfs taken geoutsourcet worden, is het van belang dat de stakeholders, i.c. de commerciële afdelingen en de directie, garanties krijgen over de geleverde ICT-dienstverlening. Deze garanties zijn onder andere te geven via service level agreements, doch de praktijk wijst uit dat bedrijven en afdelingen steeds vaker een ‘in-control statement’ (ICS) moeten afgeven op de specifieke rol die zij in de ICT-dienstverlening vervullen. In een dienst als cryptografie speelt key management een kritieke rol. Key management kan bij grote organisaties, onder andere door functiescheiding, afdelingoverschrijdend zijn. En daarom is een ICS wenselijk. Indien de focus gelegd wordt op ”het stellen van kwaliteitseisen” door de commerciële afdelingen en/of de directie, moet men denken aan eisen als: voldoen aan wettelijke eisen; bedrijfsdoelstellingen; risico’s en geaccepteerde risico’s in ICT-infrastructuur en bedrijfsprocessen.

1.1

Aanleiding

De Rabobank maakt gebruik van cryptografische diensten en vele sleutels die beheerd moeten worden. Omdat cryptografie binnen de Rabobank voor steeds meer toepassingen binnen steeds meer afdelingen (en bijbehorende producten) gebruikt wordt, zijn in de loop der tijd een niet eenduidig overzicht en beheer van key management activiteiten ontstaan. Ook de diverse reorganisaties en het personeelsverloop hebben hier een bijdrage aan geleverd. Het gevolg is een niet beheerste omgeving, doordat: kennis en verantwoordelijkheden niet eenduidig belegd zijn, waarmee de continuïteit in gevaar komt; het huidige proces niet beschreven staat, maar steunt op informele contacten; er niet volledig voldaan wordt aan de geldende normen; er geen duidelijke functiescheiding aanwezig is. Het niet eenduidig beheersen van het key management proces leidt tot een inefficiënte werkwijze waarbij tevens niet altijd voldaan wordt aan de diverse key management wetten, standaarden en richtlijnen die voor de diverse bankproducten van toepassing zijn. Vooral de externe weten regelgeving, bijvoorbeeld SOx, Basel II, ROB en Tabaksblat, stelt steeds meer eisen aan processen en vraagt hiervoor om een zogenaamde ‘in-control statement’, waarmee de onderneming aangeeft processen (voldoende) te beheersen. Uiteraard moet hierbij opgemerkt worden dat een dergelijk ‘in-control statement’ alleen afgegeven zou moeten worden bij processen waarbij het ontbreken van een beveiligingsmaatregel als cryptografie, ernstige operationele, financiële, juridische en imagoschade voor het de organisatie met zich mee zou brengen.



Pagina 5 van 32

1.2

Toelichting omgeving en problematiek

Omgeving Binnen het betalingsverkeer wordt een onderscheid gemaakt tussen het pas-uitgifte proces, issuing en transactie verwerkende proces, acquiring. Beiden hebben veel vertrouwelijke communicatie tussen verschillende partijen gemeen en zullen kort toegelicht worden. Issuing Issuing is het proces van (betaal) pas initiatie en aanmaak. De klant verzoekt de bank om een betaalpas. De bank verzamelt de benodigde informatie en stuurt die door naar een externe partij die de datapreparatie uitvoert. In dat proces worden specifieke pasgegevens aangemaakt en wordt de pincode gegenereerd. Deze wordt vanuit deze externe partij naar de klant gestuurd. De data is hiermee klaar om op de magneetstrip en/of chip op de pas gedrukt te worden en wordt doorgestuurd naar de partij die de pas fysiek aanmaakt. Na aanmaak van de pas wordt deze naar de klant gestuurd waarmee deze de pas en bijbehorende pincode dus in zijn bezit heeft. Bij dit proces zijn drie verschillende (externe) partijen betrokken waartussen data getransporteerd moet worden. Ten behoeve van de vertrouwelijkheid en integriteit van de data wordt tijdens deze communicatiestromen cryptografie toegepast. Acquiring Nu de klant in het bezit is van de pas, wil hij deze kunnen gebruiken voor geldmutaties. Hierbij kan geld opgenomen, gestort of overgemaakt worden. Voor deze toepassingen wordt gebruik gemaakt van een scala van apparaten zoals bijvoorbeeld een geldautomaat (opname), een stortingsapparaat (geld storten op rekening) of een betaalautomaat (overmaking). Bij initialisatie van deze apparaten dient een (hoofd)sleutel geladen te worden. Omdat hierbij gebruik wordt gemaakt van verschillende apparaten met weer verschillende producenten, ontstaat een netwerk van partijen waartussen sleutels uitgewisseld moeten worden. Net als de communicatiestromen bij issuing, wordt cryptografie toegepast ten behoeve van de vertrouwelijkheid en integriteit van de data. De communicatiestromen bij acquiring worden transactiestromen genoemd. Omdat cryptografie steunt op cryptografische sleutels, is het key management van groot belang. Indien sleutels niet zorgvuldig en overeenkomstig (bancaire) normen worden beheerd, kunnen bovengenoemde processen leiden tot financiële en/of imago schade.



Pagina 6 van 32

1.3 Afbakening en probleemstelling De typologie en het proces zijn ten aanzien van key management te kenmerken als een grote gedistribueerde omgeving. Voor dit proces binnen deze omgeving willen we onderzoeken of hier een generiek model voor te ontwikkelen is. Dit maakt dat we geen specifieke aandacht besteden aan andere aspecten van key management zoals: het certificeren van asymmetrische sleutels; cryptografie ten behoeve van opslag van gegevens (file encryptie); cryptografie ten behoeve van secure email (Pretty Good Privacy); cryptografie voor koppelingen op basis van Vitual Private Network. De probleemstelling voor ons onderzoek luidt: Is het mogelijk om een generiek model te definiëren waarmee een ‘in-control statement’ voor het proces “key management (KM)” kan worden afgegeven? Met “generiek” bedoelen we hier een algemeen toepasbare methode met algemeen toegepaste middelen, waardoor een synergie ontstaat. We gaan op zoek naar gestandaardiseerde processen die van toepassing kunnen zijn voor key management. Hierbij wordt gekeken of deze processen in zo veel mogelijk bestaande vormen ondersteuning kunnen geven. Het voordeel hiervan is dat men vaak al bekend is met het werken volgens deze methoden. Een ander belangrijk voordeel is dat een standaard proces eenvoudiger te beoordelen is. 1.3.1 Subvragen Deze onderzoeksvraag wordt vanuit de volgende subvragen geconcretiseerd: 1. 2. 3. 4. 5.

Wat is een standaard ‘in-control statement’ (ICS)? Wat is cryptografie? Wat is key management? Welke standaard is er voor een ‘in-control statement’? Welk generieke beheersprocessen kan gebruikt worden voor key management?



Pagina 7 van 32

1.4

Onderzoeksmodel

Om het onderzoek uit te voeren, is een onderzoeksmodel gedefinieerd zoals weergegeven wordt in figuur 2. Het model beschrijft de stappen die doorlopen zijn.

Figuur 2: Onderzoeksmodel



Pagina 8 van 32

1.5

Gegevens Betreft

1.

Auteurs Naam

AH Schilp (Arie)

R van Erven (Ronald)

Student nummer

9981189

9981162

Naam werkgever

Rabobank Nederland / Groep ICT; Informatie Security Manager Postbus 17100 3500 HG Utrecht

Tele2-Versatel; ICT Security officer

Telefoonnummer

0302161762; 0622548648

e-mailadres

[email protected]

0207502227 (altijd naar mobiel doorgeschakeld); 0334564998 [email protected]

Adres

2.

1.6

PH Samwel RE(Rabobank Nederland, Hoofd Informatie en Risico Management; email: [email protected]; tel: 0302152548

Externe begeleider Naam

4.

JJP Oudpad 15; 3822 EN; Amersfoort

Interne begeleider Naam

3.

Gegevens

File

B. Bokhorst ( email: [email protected] ; [email protected]; telefoon: 0555283297 / 0618608920 ) 719

Leeswijzer

In dit hoofdstuk is de aanleiding voor het onderzoek geformuleerd en is de probleemstelling verwoord. Hoofdstuk 1 is ingericht voor de inleidende en algemene informatie. In hoofdstuk 2 geven we de achtergrondinformatie van de aspecten die van belang waren voor ons onderzoek, te weten ‘in control’, cryptografie en key management. In hoofdstuk 3 zijn we nader ingegaan op het standaard beheerproces ITIL. De relatie tussen key management en ITIL, de zogenaamde modellering, wordt in hoofdstuk 4 beschreven. Het generieke model volgt in hoofdstuk 5. Hoofdstuk 6 ten slotte bevat onze conclusie en het antwoord op onze onderzoeksvraag.

2 Uitwerking probleemstelling 2.1

In control

Aanleiding Voordat we ingaan op ‘in control’, eerst een korte toelichting op de oorsprong hiervan. De aanleiding is vooral de externe weten regelgeving. De regelingen van Sarbanes Oxley Act (SOx), Regeling Organisatie en Beheersing (ROB), Basel II en de Code Tabaksblat hebben ervoor gezorgd dat organisaties meer belang (moeten) hechten aan het ‘in control’ zijn en de rapportage daarvan. Sarbanes-Oxley Act Naar aanleiding van de boekhoudfraudes, is in 2002 in de Verenigde Staten de U.S. Public Company Accounting Reform and Investor Protection Act van kracht geworden. Deze is inmiddels meer bekend als de Sarbanes-Oxley Act, ook wel afgekort tot SOx. Doel was om frauduleuze praktijken binnen beursgenoteerde organisaties tegen te gaan. Alle in de VS aan de beurs genoteerde organisaties dienen te voldoen aan de Sarbanes-Oxley reglementen. Handelspartners van de ondernemingen die aan de SOx voldoen, worden ook meegezogen in deze stroom: de informatieprocessen van handelspartners worden immers gekoppeld. Feitelijk stelt SOx daarmee haar eisen ook aan deze ondernemingen. SOx dient ertoe te leiden dat de (totstandkoming van de) financiële verslaglegging betrouwbaar is. Betrouwbaar in de termen van juist en volledig. Het management moet ‘in control’ zijn, hetgeen betekent dat processen beschreven dienen te zijn inclusief de beheersingsmaatregelen binnen de processen. Regeling Organisatie en Beheersing De Regeling Organisatie en Beheersing (ROB) is opgesteld door De Nederlandsche Bank (DNB) en vervangt een aantal richtlijnen en aanbevelingen die DNB in het verleden heeft uitgevaardigd ten behoeve van financiële instellingen. De regeling heeft tot doel richtlijnen en aanbevelingen te geven voor de organisatie en beheersing van bedrijfsprocessen en onderscheidt de volgende specifieke risicogebieden: -

Kredietrisico Marktrisico Liquiditeitsrisico Operationeel risico Informatietechnologie Uitbesteding van (delen van) bedrijfsprocessen Integriteitsrisico Rechten en plichten van (potentiële) cliënten.

In de ROB is onderscheid gemaakt tussen ‘richtlijnen’ (met een verplichtend karakter) en ‘aanbevelingen’ (die weliswaar geen verplichtend karakter hebben, maar waarvan de instelling alleen op goede gronden mag afwijken). In artikel 7 van [ROB]staat: het zorgdragen voor de uitwerking en implementatie van de beleidsuitgangspunten ter beheersing van IT-risico’s in zichtbare organisatorische en administratieve procedures en maatregelen, welke geïntegreerd zijn in de IT-processen en de dagelijkse werkzaamheden van alle relevante geledingen. Hier ligt wat ons betreft de link naar een beheerst IT-proces, waarop we ons generiek model willen aanpassen.



Pagina 10 van 32

Waar de ROB zich voornamelijk richt op de inhoud, de wijze waarop risicomanagement dient te worden georganiseerd binnen de bank, richt Basel II zich meer op de processen en de structuren voor deze processen. Basel II In 1930 is de internationale financiële organisatie Bank for International Settlements (BIS) opgericht. Het doel van BIS is de samenwerking tussen nationale centrale banken te bevorderen. Zo wordt het toezicht dat de nationale centrale banken uitoefenen op de commerciële banken, op elkaar afgestemd. Dat was nodig omdat door de internationalisering de concurrentie tussen bancaire instellingen werd verhevigd. Medio jaren tachtig zette deze concurrentiestrijd verder door en werd als gevolg hiervan steeds minder eigen vermogen in relatie tot de verstrekte kredieten aangehouden. Deze verslechterende solvabiliteit leidde tot hoge risico’s. Toezicht en afspraken waren noodzakelijk om de financiële markten te beschermen. In 1988 zijn hiervoor richtlijnen vastgesteld die door de nationale centrale banken van de grote landen zijn overgenomen. De overige landen volgden later. De richtlijn bepaalt dat een bank tegenover elke kredietverstrekking een bepaald percentage van dat bedrag als eigen vermogen moet aanhouden. Deze richtlijn is genoemd naar de plaats waarin de BIS is gevestigd en is bekend geworden als Basel I. Met de toepassing van Basel I kwamen er diverse nadelen van het systeem naar boven. Zo was het te veel toegespitst op het in- en uitlenen van geld, terwijl de werkelijkheid veel dynamischer bleek. Daarom is vanaf 1996 gewerkt aan een nieuwe richtlijn. Deze opvolger is dan ook Basel II genoemd. Basel II gaat niet meer alleen uit van kredietrisico’s maar ook van markten operationele risico’s. Per aandachtsgebied dient een kapitaalsreservering berekend en aangehouden te worden. Voor ons onderzoek is vooral het operationele risico van belang. Hieronder verstaan we de risico’s die voortkomen uit falende of onjuiste interne processen, mensen en systemen of externe gebeurtenissen. Code Tabaksblat Zijn de financiële instellingen als gevolg van de ROB gebonden aan een verklaring over risicobeheersing, vanaf januari 2004 zijn alle vennootschappen met hun statutaire zetel in Nederland en waarvan (certificaten van) aandelen zijn toegelaten tot de officiële notering van een van overheidswege erkende effectenbeurs, gehouden aan de Nederlandse Corporate Governance Code. In 2003 werd in Nederland een commissie samengesteld die gevraagd werd een opvolging van het rapport “Corporate Governance in Nederland; De Veertig Aanbevelingen” uit 1997 van de commissie Peters te ontwikkelen. Omdat deze commissie onder leiding van Morris Tabaksblat stond, wordt deze Governance Code ook wel de Code Tabaksblat genoemd. Deze code is gericht op het functioneren van de leden van de Raad van Bestuur, de macht van de commissarissen en de invloed van de aandeelhouders. Zo wordt voor de Raad van Bestuur (II.1 Taak en werkwijze) gesteld dat deze verantwoordelijk is voor het beheersen van de risico’s die verbonden zijn aan de ondernemingsactiviteiten. In de best-practice bepaling van dit hoofdstuk [TABAK] staat onder II.1.4: In het jaarverslag verklaart het bestuur dat de interne risicobeheersing- en controlesystemen adequaat en effectief zijn en geeft het een duidelijke onderbouwing van deze verklaring. Bij de code geldt de ‘pas toe of leg uit’-regel: beursgenoteerde ondernemingen dienen in het jaarverslag aan te geven of zij de codevoorschriften toepassen en zo niet, waarom niet. Deze ‘pas toe of leg uit’-regel is wettelijk vastgelegd.



Pagina 11 van 32

2.1.1 Definitie In control De definitie die Driesen, Kamstra en Molenkamp geven aan ‘in control’ is: De wijze van sturen, beheersen en toezicht houden, gericht op een effectieve en efficiënte realisatie van strategische en operationele doelstellingen alsmede het hierover op een open wijze communiceren en verantwoording afleggen ten behoeve van de belanghebbende. In het kader van dit onderzoek richten wij ons meer op het proces zelf. Een generiek model zou moeten borgen dat het key management proces een beheerst proces is. Onze definitie voor ‘in control’ luidt dan ook: Een proces is’in control’ als het aantoonbaar beheerst wordt tot op een niveau dat van dat proces vereist mag worden (goed huisvaderschap) aan de hand van voorafgestelde normen (eisen). 2.1.2 In-control statement Uit bovenstaande blijkt dat er voldoende aanleidingen zijn voor een ‘in-control statement’ (ICS). Omdat steeds meer organisaties afzonderlijke processen ‘in control’ willen verklaren, willen wij onderzoeken hoe voor het key management proces een ICS afgegeven kan worden. Allereerst dient aangegeven te worden wat een dergelijke ICS nu precies inhoudt. ICS is afgeleid van het ‘Statement of Control’, dat in de Verenigde Staten door het management wordt afgegeven aan de aandeelhouders. Het management geeft hiermee aan in hoeverre het voldoende grip heeft op de bedrijfsprocessen. De introductie van SOx heeft zo’n statement geformaliseerd. Met betrekking tot ICS wordt binnen SOx de wijze aangegeven waarop in het algemeen met risico’s wordt omgegaan en dan nog alleen wat betreft de financiële informatieverstrekking. Maar inmiddels zijn er ontwikkelingen die maken dat organisaties nu verder (moeten) gaan met ICS. In hun artikel In Control Statements [DRIES] geven de schrijvers Driessen, Kampstra en Molenkamp aan dat ‘in control’ verder kan gaan dan wat SOx beschrijft. Hiermee bedoelen zij dat een ICS primair aangeeft in hoeverre de organisatie beheersmaatregelen heeft getroffen om risico’s af te dekken en op basis daarvan de tekortkomingen kan identificeren. Immers, Basel II schrijft voor dat er afhankelijk van het te lopen risico een kapitaalsreservering dient plaats te vinden. Dit maakt dat beheersing van operationeel risico voor de banken dus van groot belang is. Hiermee hebben we de eerste sub-onderzoeksvraag beantwoord. Duidelijk is dat vooral externe weten regelgeving voor meer aandacht voor ‘in control’ heeft gezorgd. Gesteld kan worden dat ‘in control’ afdaalt van de financiële wereld naar de specifieke IT-processen. Bij een aantal bedrijven wordt bijvoorbeeld aan informatiebeveiliging gevraagd of de organisatie ‘in control’ is op het gebied van informatiebeveiliging [CIOPL]. Gezien het belang van key management, kan deze verklaring hiernaar toe doorgetrokken worden. 2.1.3 Eisen aan een “in-control statement” (ICS) Op zich zijn er geen eisen gesteld aan een standaard rapportage. Deze wordt in overleg bepaald tussen opdrachtgever, auditor en auditee. Om te voorkomen dat er een diversiteit aan ‘in-control statement’ ontstaat, is de rapportage standaard SAS70 ontwikkeld. Doel van deze standaard is niet alleen om audit efficiency te bereiken, maar ook om te kunnen benchmarken tussen vergelijkbare bedrijven en processen. SAS70 stelt eisen aan de wijze van een rapportage. SAS70 staat voor “Statement on Auditing Standards number 70”, een door het American Institute of Certified Public Accountants (AICPA) opgestelde norm voor certificering van procesbeheersing. Een SAS70-rapport biedt een gedetailleerd inzicht in de wijze waarop een organisatie de kwaliteit van haar dienstverlening waarborgt.



Pagina 12 van 32

Rapportagevorm voor een ICS op basis van SAS-70 [AICPA] Voor SAS-70 bestaan een type-I en een type-II rapport. Type I: momentopname Een type-I rapport beschrijft de getroffen beheersmaatregelen (controls) die op een bepaald moment zijn geïmplementeerd en waarmee de beheersdoelstellingen (control objectives) kunnen worden bereikt. De beschrijving wordt ondersteund door een rapport van de externe auditor dat aangeeft of de maatregelen toereikend zijn om de beheersdoelstellingen te realiseren en of deze op de specifiek genoemde datum daadwerkelijk waren geïmplementeerd. Type II: uitspraak over een bepaalde periode Een type-II rapport heeft betrekking op een periode – minimaal 6 maanden – waarin de beschreven beheersmaatregelen aanwezig waren om de beheersdoelstellingen te bereiken. Ook is het rapport van de externe auditor uitgebreid met een oordeel over de werking van de maatregelen in deze periode. De opbouw van het SAS-70 rapport Een SAS-70 rapport bestaat uit verschillende secties, namelijk: Sectie 0 De geheimhoudingsverklaring. De auditors, de auditee en de opdrachtgever komen hierin overeen dat het rapport alleen gebruikt wordt in het kader van de opdracht en dat de inhoud hiervan niet op andere wijze openbaar wordt gemaakt. De geheimhoudingsverklaring is niet een standaard sectie uit SAS70, maar is een best practice die door steeds meer bedrijven word overgenomen. In de Verenigde Staten worden geheimdhoudings verklaringen in een apart contract geregeld, doch van uit het Verenigd Koninkrijk vonden accountants bedrijven het nodig om dit een onderdeel van het SAS70 rapport. Sectie I “Independent Service Auditors’ Report” – omvat alleen het oordeel van de auditor en niet het gehele rapport. Deze sectie, de eigenlijke in-control statement, is de verantwoordelijkheid van de externe auditor. Sectie II “Description of Controls and Procedures” – de ICT-dienstverlener dient naast een overzicht van de dienstverlening en de organisatie een beschrijving te geven van de interne beheersing onderverdeeld naar de vijf componenten van het referentieraamwerk van COSO (Committee of Sponsoring Organizations of the Treadway Commission). Deze vijf componenten zijn: -

Control Environment: beschrijft de integriteit, ethische waarden en competenties van het personeel en de managementfilosofie en managementstijl; Risk Assessment: omvat de identificatie en analyse van risico’s die relevant zijn voor het bepalen van maatregelen voor risicobeheersing; Control Activities: de processen en procedures die de doelstelling van het management helpen te waarborgen; Information and Communication: richt zich op de aard en kwaliteit van de informatie die nodig is voor een effectief bestuur en rapportages; Monitoring: omvat de component die de kwaliteit en effectiviteit van de processen toetst.



Pagina 13 van 32

De ICT-dienstverlener is verantwoordelijk voor het opstellen van deze sectie. De auditor is verantwoordelijk voor het doornemen van deze beschrijving en het bepalen van de geschiktheid van de opzet van de ‘controls’. Sectie III “Tests of Operating Effectiveness” – In deze sectie worden de beheersmaatregelen (‘controls’) getoetst die door ICT-dienstverlener zijn vastgesteld. Voor een type-I verklaring omvat deze toetsing “opzet” en “bestaan” en voor een type-II verklaring omvat het alleen de werking. De auditor toetst de beheersmaatregelen door middel van Inquiry (interview), Inspection (inspectie van documenten), Observation (waarnemen) en Reperformance (opnieuw uitvoeren). De mate van testen van de beheersmaatregelen is afhankelijk van het aantal keer dat de testen worden uitgevoerd. De auditor is verantwoordelijk voor deze sectie. Opgemerkt dient te worden dat de wijze van controle “rule based” is, in tegenstelling tot “principle based”, waarbij het mogelijk is om aan bestaan en werking te voldoen ook al is opzet niet aanwezig. Bij rule-based auditing is het zo dat indien opzet niet aangetoond kan worden, bestaan niet aanwezig is en dat als bestaan niet aanwezig is, er geen sprake kan zijn van werking. Sectie IV “Other Information Provided by Service Organization” – Deze sectie geeft ruimte aan ICTdienstverlener voor het geven van extra informatie. Hierbij kan het gaan om informatie over bijvoorbeeld continuïteit en geplande significante projecten of systeemconversies. Met de beschrijving van deze vorm van rapporteren is de tweede sub-onderzoeksvraag behandeld en kan deze rapportage ook voor key management worden toegepast.

2.2

Cryptografie

In dit hoofdstuk komen de aspecten met betrekking tot de derde sub-onderzoeksvraag aan de orde, waarbij tevens nader wordt ingegaan op de vormen en toepassingsgebieden van cryptografie. 2.2.1 Wat is cryptografie Het woord cryptologie is een combinatie van de Griekse woorden “kruptus” en “logos”, die “verborgen” en “woord” betekenen. Binnen cryptologie kan onderscheid gemaakt worden tussen cryptografie en cryptoanalyse. Ons onderzoek heeft betrekking op cryptografie. Van der Lubbe [LUBBE] omschrijft cryptografie als: dat deel van cryptologie dat zich bezighoudt met technieken om data te versluieren of te vercijferen, waarbij veelal gebruik wordt gemaakt van geheime sleutels. Hierbij geldt dat het versluieren van data “encryptie” wordt genoemd, en het ontcijferen “decryptie”. Cryptografie bestaat al sinds lange tijd en werd van oorsprong alleen toegepast om informatie te versluieren. De boodschap die verzonden werd, mocht alleen door de partij gelezen worden waarmee een afspraak over de versluiering was gemaakt. De eerste toepassing werd uitgevoerd door Julius Caesar om berichten naar het front te sturen. Vooral militaire toepassingen hebben ertoe geleid dat cryptografie in de loop der jaren verder geëvolueerd is. Een bekend voorbeeld is de enigma-machine die voor en tijdens de Tweede Wereldoorlog door Duitsland gebruikt werd. De afspraken die voor de toepassing van cryptografie noodzakelijk zijn, betreffen het toegepaste algoritme (de wijze waarop het doel wordt bereikt) en de bijbehorende sleutel. De Teamnummer Auteur(s) Datum Versie


Pagina 14 van 32

berichten van Caesar werden bijvoorbeeld versluierd door elke letter van een bericht te vervangen door een letter die drie plaatsen verder in het alfabet staat. Deze methode is dus gebaseerd op substitutie. Een andere methode is bijvoorbeeld transpositie. Hierbij veranderen letters van plaats. Substitutie en transpositie worden vaak gecombineerd als algoritme toegepast. Het toegepaste algoritme bij cryptografie is niet geheim. Twee overwegingen hiervoor zijn: 1) het algoritme kan door leveranciers als standaard in diverse hardware worden opgenomen; 2) door het algoritme vrij te geven kan het indringend getest worden, waardoor mogelijke fouten (snel) ontdekt worden. Naast het algoritme is daarom een geheime sleutel benodigd. Deze sleutel (de mogelijke waarde waarmee het doel wordt bereikt) is hiermee de kern van cryptografie en dient hierom goed beheerd te worden. Het zogenaamde Caesar-algoritme vond plaats op basis van een gedeeld geheim waarmee de vertrouwelijkheid van een bericht kon worden gewaarborgd. Deze vorm heet symmetrische cryptografie. Midden jaren zestig werd een nieuwe techniek ontwikkeld waarbij op basis van wiskundige functies twee sleutels een onlosmakelijk verband met elkaar hebben, de asymmetrische cryptografie. 2.2.2

Vormen van cryptografie

Symmetrische cryptografie Bij symmetrisch cryptografie wordt één sleutel gedeeld tussen de zender en de ontvanger. Met deze sleutel wordt het bericht door de zender encrypt (cipher text) en kan de ontvanger het door decryptie weer leesbaar maken (plain text). Een bekende vorm van symmetrische cryptografie is: Data Encryption Standard. DES is ontwikkeld in de jaren zeventig door IBM, en werd in 1976 de standaard cryptografische methode voor de Amerikaanse overheid. DES werkt op basis van een combinatie van transpositie en substitutie. Hierbij is de veiligheid afhankelijk van de sleutellengte. Indien de sleutellengte 56 bits bedraagt, zijn er 256 sleutels mogelijk. In de afgelopen jaren is het mogelijk gebleken de DES sleutel te achterhalen via een brutekrachtaanval. Hierbij worden door (steeds krachtigere) computers onuitputtelijk nieuwe sleutels uitgeprobeerd, net zolang totdat het bericht leesbaar is. In reactie hierop is Triple DES (3DES) ontwikkeld. Hierbij worden de data 3 keer vercijferd met 2 of 3 verschillende sleutels. De kans op een succesvolle brutekrachtaanval wordt hiermee aanzienlijk gereduceerd. In 1998 maakte de Electronic Frontier Foundation haar DES cracker project bekend. De EFF had dit project speciaal ontwikkeld en gefinancierd om DES te kunnen kraken. Omdat verwacht werd dat 3DES uiteindelijk ook gekraakt zou kunnen worden, schreef de Amerikaanse overheid een wedstrijd uit voor de ontwikkeling van een nieuwe cryptografiestandaard. In oktober 2000 werd het Rijndael-algoritme uit België als nieuwe standaard gekozen. Deze is inmiddels bekend als Advanced Encryption Standard (AES) en is als zodanig door de financiële wereld geadopteerd. Asymmetrische cryptografie In tegenstelling tot symmetrische cryptografie hoeven de afzender en ontvanger bij asymmetrische cryptografie niet allebei over dezelfde sleutel te beschikken om een bericht te encrypten of decrypten. Twee sleutels zijn hier van belang. Wat versleuteld wordt met de ene sleutel, kan gelezen worden met de andere sleutel en vice versa. Door één deel van de sleutel consequent geheim te houden en de ander juist openbaar te maken, kunnen verschillende technieken worden Teamnummer Auteur(s) Datum Versie


Pagina 15 van 32

uitgevoerd. Deze sleutels noemen we respectievelijk private key en public key. Deze sleutels zijn met behulp van een priemgetal wiskundig berekend en onlosmakelijk met elkaar verbonden. De private key blijft altijd in eigen bezit en moet geheim blijven. De public key daarentegen wordt juist gepubliceerd. Degene die een bericht wil versturen of ontcijferen, kan dan deze sleutel opzoeken en gebruiken. Het hele infrastructuur rondom (a)symmetrische cryptografie wordt ook wel aangeduid als Public Key Infrastructure (PKI). Naast het versluieren van een bericht kan PKI ook zorgen voor authenticatie van de afzender, de integriteit van het bericht en de onweerlegbaarheid. PKI werd in 1976 uitgevonden door Whitfield Diffi en Martin Hellman. Een bekend en veel toegepast algoritme is het RSA-algoritme, dat in 1978 werd uitgevonden door Ron Rivest, Adi Shamir en Leonard Adleman. PKI biedt meer mogelijkheden dan symmetrische cryptografie, maar is complexer door de organisatorische consequentie. Ontvangende partijen willen zekerheid dat de publieke sleutel die ze verkrijgen, ook inderdaad afkomstig is van de partij die deze uitgeeft. Hiervoor is een derde partij (Trusted Third Party, TTP) actief. De TTP stelt een (digitaal) certificaat op waarmee de verbintenis tussen de identiteit van de aanvrager en haar publieke sleutel wordt bevestigd. Een TTP die certificaten uitgeeft, wordt ook wel Certificate Authority (CA) genoemd. Toepassingsgebieden Zoals eerder aangegeven, werd cryptografie van oorsprong toegepast voor versluiering van berichten. Zowel symmetrische als asymmetrische cryptografie kan de vertrouwelijkheid van een bericht waarborgen. Hieronder in figuur 3, een grafische voorstelling daarvan, waarbij de symmetrische cryptografie plaatsvindt met de (gedeelde) sleutel AB en bij asymmetrische cryptografie met het sleutelpaar van partij B.

Figuur 3: Vertrouwelijkheid obv cryptografie

Door toepassing van de juiste (combinatie van) cryptografische bewerkingen kunnen de volgende beveiligingsaspecten gewaarborgd worden: Vertrouwelijkheid Integriteit Authenticiteit Onweerlegbaarheid

: onbekenden kunnen het bericht niet inzien. : de inhoud van het bericht kan niet onopgemerkt gewijzigd worden. : zekerheid over de zender van het bericht. : een partij kan niet ontkennen het bericht verstuurd te hebben.

Het voordeel van DES/3DES is dat het een betrouwbaar en relatief goedkoop en snel algoritme is dat eenvoudig in de hardware is te realiseren. Door deze voordelen wordt het veel gebruikt in de financiële wereld. Het probleem is echter de uitwisseling van de sleutel. Een algemene norm is dat een sleutel nooit in klare tekst mag voorkomen, dus zijn er diverse methodes ontwikkeld om de sleutel veilig te transporteren. De komst van asymmetrische cryptografie biedt hierbij een goede oplossing. Omdat bij deze vorm van cryptografie een Teamnummer Auteur(s) Datum Versie


Pagina 16 van 32

grote sleutellengte nodig is, vergt de versluiering van (grote) berichten veel rekenkracht. In de financiële wereld wordt daarom cryptografie van berichten zelf met symmetrische sleutels toegepast en vindt uitwisseling van die sleutels steeds vaker plaats met behulp van asymmetrische cryptografie.

2.3

Key management

Zoals geschetst is een essentieel onderdeel van cryptografie de “sleutel”. Indien de sleutel openbaar zou worden, kan de informatie openbaar worden gemaakt of worden gewijzigd. Dit kan schade veroorzaken voor het bedrijf of de persoon die de informatie had versleuteld. Het beheer van sleutels is daarom een voorwaarde om welke vorm van cryptografie dan ook toe te passen. De Engelse en meer gangbare term voor sleutelbeheer is key management. 2.3.1 Key management als een proces Key management bestaat uit een aantal fasen, de zogenaamde life cycle van sleutels. Deze start bij de generatie en eindigt bij het vernietigen van een sleutel. Elke fase is erop gericht om de vertrouwelijkheid, integriteit en continuïteit van de sleutels te ondersteunen. De key life cycle kan gezien worden als (generiek) model. In onderstaande figuur 4, staat het model met de specifieke fasen vermeld.

Figuur 4: Key Management Life Cycle [KPMG]

De fasen zijn als volgt te beschrijven [KPMG]. Activiteit Asymmetrische Symmetrische & publieke Asymmetrische sleutels geheime sleutels Key (pair) X X generation Key registration X Key distribution Key repository Key usage Key revocation Key expiration Key backup Key installation Key termination Key archival Restricted key usage


X X X X X

X X

X X X X X

Omschrijving Het aanmaken van een sleutel of sleutelparen Het registreren van sleuteluitgifte. Het gaat hier niet om de inhoudelijke sleutel maar meer aan welke persoon of instantie een sleutel is gegeven Het distribueren van sleutels Een CMDB van alle sleutels Sleutelgebruik Het intrekken van sleutels Het laten verlopen van sleutels Het maken van een backup van sleutels Het installeren van een sleutel / sleutels Het vernietigen van sleutels Het archiveren van sleutels Het gebruik van sleutels door een beperkte groep personen in het geval van herstel (recovery) van sleutels


Pagina 17 van 32

De life cycle is een bestaand generiek model voor key management. Hieronder een korte beschrijving van de belangrijkste onderdelen hiervan met de (audit) aspecten waarop gelet kan worden. Het is geen limitatieve weergave van alle eisen die hieraan gesteld worden. Hiervoor wordt verwezen naar de diverse normenkaders zoals: ISO: International Standard Organisation FIPS: Federal Information Processing Standard (officiële standaard voor de Verenigde Staten en uitgegeven door de National Institute of Standards & Technology) PKCS: Public Key Cryptography Standards, specifiek voor asymmetrische cryptografie (PKI) ANSI: American National Standards Institute ECBS: European Committee for Banking Standards Verder zijn er in het betalingsverkeer diverse (uitgevende) instanties met specifieke(re) eisen, zoals: EMVco: de eisen van de creditkaart uitgevende instanties VISA en MasterCard ten behoeve van het betaalschema via EMV, waarbij de transactie niet meer vanaf de magneetstripinformatie wordt geïnitieerd, maar vanuit de chip PCI: Payment Card Industry: meer algemene eisen vanuit VISA en MasterCard Key generation Het genereren van sleutels dient zodanig plaats te vinden dat de sleutel nooit buiten het generatie-device leesbaar (in klare tekst) gepresenteerd wordt. Dit kan door fysieke en logische afscherming van de omgevingen waarbinnen dit proces plaatsvindt. De presentatie van de sleutels kan vervolgens plaatsvinden door: delen van de klare waarde direct in afgeschermde enveloppen te printen de gegenereerde sleutel direct te versleutelen met een andere sleutel en (delen hiervan) uit te printen op zogenaamde sleutelbrieven of op te slaan in een apart device Het generatieproces dient onvoorspelbare sleutels te genereren. Hiervoor dient het device te voldoen aan met name de eisen van FIPS 140-2. Voor de AO/IC is het belangrijk dat de generatie plaatsvindt onder toezicht van een toezichthouder en, bij voorkeur, de betrokken key custodians. De toezichthouder controleert of het proces juist en integer verloopt. De key custodians zijn de medewerkers die de delen van de sleutels in ontvangst nemen en uiteindelijk invoeren. Key distribution De gegenereerde sleutel dient veilig gedistribueerd te worden. Dit kan encrypt onder een andere sleutel of via sleutelbrieven. Deze dienen bij voorkeur aan de verschillende key custodians persoonlijk overhandigd te worden. Een alternatief is verzending per post. De procedure hiervoor is dat de ontvangende key custodians vooraf zijn aangemeld. De aanleverende partij verzendt de sleuteldelen vervolgens aangetekend via een koerier. Nadat de ontvangst van het eerste deel is bevestigd, worden de volgende delen -eveneens aangetekendvia andere koeriers verstuurd. Key installation Het installeren van de sleutels dient onder toezicht te gebeuren overeenkomstig ISO 11568. Ten behoeve van de vertrouwelijkheid mogen de sleutels alleen opgeslagen worden in een security device, encrypt onder een andere sleutel of in gescheiden delen. Deze handelingen worden door de toezichthouder vastgelegd en ondertekend door betrokken personen. De vastlegging wordt vervolgens geadministreerd bij de key manager. Ter controle van een juiste installatie wordt bij generatie een Key Check Value toegevoegd. Hierbij wordt de originele sleutel met een zogenaamde one-way encryption methode versleuteld met een bepaalde standaard waarde. Door na het installeren dezelfde berekening na het installeren uit te voeren kan de verkregen waarde vergeleken worden met de opgegeven waarde. Teamnummer Auteur(s) Datum Versie


Pagina 18 van 32

Key use Uiteindelijk moet een sleutel daadwerkelijk gebruikt worden, waarbij de volgende aspecten van belang zijn: de sleutel mag niet ongeautoriseerd worden toegepast; de sleutel mag alleen voor dat doel worden toegepast waarvoor deze is gegenereerd; de sleutel mag gedeeld worden tussen maximaal twee partijen. Verder mag de cryptografische handeling alleen plaatsvinden in een speciaal daarvoor bestemd apparaat en mag er geen sleuteluitwisseling tussen testen productieomgevingen plaatsvinden. Key back-up De devices waarin sleutels geladen worden, zijn vaak voorzien van een fysieke maatregel, de tamper resistance. Dit betekent dat bij grove fysieke toenadering van het device de inhoud gewist wordt. In dat geval moet een sleutel teruggezet kunnen worden. Een duplicaat of trilicaat van sleutels moet bewaard worden op fysiek gescheiden locaties. Indien de sleutel elektronisch wordt bewaard, gelden hier dezelfde regels voor als in de productionele omgeving. Als de sleutel(delen) op sleutelbrieven worden bewaard, moeten deze in (aparte) kluizen bewaard worden. De toegang tot deze kluizen mag, met toepassing van functiescheiding, alleen plaatsvinden door geautoriseerd personeel. Key archive Waar de back-up van de sleutel van belang is tijdens de actieve levensduur van de sleutel, is archivering dat nadat de sleutel zelf niet meer toegepast wordt. Denk bijvoorbeeld aan gegevens die encrypt zijn opgeslagen en als gevolg van wet- of regelgeving toch reproduceerbaar moeten blijven. Voor archivering gelden dezelfde eisen als voor back-up. Key termination Als een sleutel verlopen is en geen dienst meer doet, kan vernietiging plaatsvinden. Bij vernietiging moeten de sleutels in alle omgevingen waarin deze voorkomen, worden meegenomen. Ingeval een sleutel nog als back-up voorkomt op sleutelbrieven, dienen deze ook (gecontroleerd) vernietigd te worden.



Pagina 19 van 32

3 Beheersprocessen 3.1

Standaard beheersprocessen (ITIL)

Doordat organisaties in toenemende mate afhankelijkheid zijn van ICT-infrastructuren en ICT-afdelingen, zijn er beheersprocessen ontworpen. Met deze beheersprocessen zijn de ICTafdelingen beter aan te sturen en wordt afstemming bereikt tussen de bedrijfsdoelstellingen en de inzet van ICT-middelen. Een veel voorkomend referentiekader voor een beheersproces is ITIL (IT Infrastructure Library). ITIL is een set van best practices die een praktisch inrichtingskader biedt. Een ander voordeel van het toepassen van beheersprocessen als gedefinieerd in ITIL is dat er gebruik wordt gemaakt van gestandaardiseerde processen, zodat beheeractiviteiten efficiënter uitgevoerd kunnen worden. Mede hierdoor kunnen de ICT-organisatie en -infrastructuur eenvoudig(er) gecontroleerd worden [ITSM]. Het doel is het continu verhogen van de kwaliteit en het beheersen, oftewel in control zijn, van de ICT-dienstverlening. De kern van ITIL bestaat uit processen op tactisch en operationeel niveau. Omdat key management ten dienste staat van de cryptografie, zien wij dit als een operationeel proces, binnen ITIL ook wel Service Support genoemd. Het tactische niveau, de Service Delivery, sluit hierop aan. Figuur 5 toont een schematische weergave van ITIL, met de onderverdeling van Service Support en Service Delivery.

Figuur 5: ITIL Service Support en Delivery; bron EXIN



Pagina 20 van 32

4 Modellering Omdat de Rabobank reeds volgens de ITIL-structuur werkt, is het voor ons een belangrijk uitgangspunt geweest het key management proces te spiegelen aan de diverse ITIL-processen uit de Service Support set. De koppeling naar de Service Delivery leggen we via het ServiceLevel Management proces. Door de generieke modellen key life cycle en ITIL aan elkaar te relateren, ontstaat er een omgeving die aantoonbaar beheerst kan worden, omdat voor de genoemde modellen al diverse normenkaders aanwezig zijn waarmee de auditability wordt vergroot. Met de opname van de (meta-data van de) sleutel in de CMDB vindt de integratie tussen de operatie en beheer plaats. De CMDB is de spil van ITIL, van waaruit de overige processen geactiveerd kunnen worden. 4.1 Prototypemodel Met de focus op de activiteiten van key management zijn wij tot onderstaande koppelingen gekomen. De motivatie van deze koppelingen wordt kort toegelicht. Een uitgebreidere uitwerking komt in het volgende hoofdstuk Generiek model aan de orde. We hebben een keuze gemaakt uit de ITIL-processen die naar onze mening een toegevoegde waarde hebben voor key management KM Life Cycle Key generation

ITIL Release Management

Omschrijving Het aanmaken van een sleutel(paar) Binnen ITIL is Release Management gericht op de versies van de software. Een sleutel generatie leidt tot een nieuwe versie van de sleutel. KM Life Cycle Key registration

ITIL Configuratie Management

Omschrijving Het registreren van sleutel uitgifte. Configuration Management omvat de registratie van IT-componenten. Vanwege de directe betrokkenheid van de sleutel voor de ondersteuning van de ICT, zien wij de sleutel als een configuration item. met registration wordt primair vastgelegd aan wie de sleutels verstrekt zijn. KM Life Cycle ITIL Omschrijving Key distribution Release Management Het distribueren van sleutels Release Management verzorgt ook de distributie van software, dus kan deze activiteit ook worden doorgetrokken naar de distributie van sleutels. KM Life Cycle Key repository

ITIL Configuratie Management

Omschrijving De opslag van de (meta-data van de) sleutel Repository omvat de beschrijving van de sleutel, welke centraal vastgelegd wordt in de CMDB. De vastlegging vormt de bron van informatie ten behoeve van beheer en kan verder als input voor andere processen dienen. KM Life Cycle Key usage

ITIL Omschrijving Operations (geen ITIL proces) Het gebruik van de sleutel, voor het doel waarvoor deze aangemaakt is. Operations is geen ITIL-proces, maar wordt vaak als onderliggend proces van ITIL beschouwd. Teamnummer Auteur(s) Datum Versie


Pagina 21 van 32

KM Life Cycle Key revocation

ITIL Change Management

Omschrijving Het intrekken van sleutels nav een opdracht van de eigenaar De eigenaar een kan via een wijzigings verzoek, opdracht geven om een sleutel in te trekken. KM Life Cycle Key expiration

ITIL Availability Management

KM Life Cycle Key back-up

ITIL Availability Management

Omschrijving Het verlopen van sleutels nav een opdracht uit het systeem Dit betreft het verlopen van een sleutel zoals vastgelegd in de SLA en aangegeven vanuit de CMDB. Omschrijving Het maken van back-up van de sleutel Een sleutel kan in verschillende vormen worden opgeslagen ten behoeve van de beschikbaarheid. Dit kan in electronische of in fysieke vorm, zoals bijvoorbeeld op papier. KM Life Cycle ITIL Omschrijving Key installation Release Management Het installeren van de sleutel De afweging was dit onder Release Management of onder Operations te plaatsen. Omdat binnen Release Management ook het plaatsen van hardware valt, is hier voor gekozen. KM Life Cycle ITIL Omschrijving Key termination Availability Management Het vernietigen van sleutels Termination maakt een gecontroleerd einde aan de beschikbaarheid. KM Life Cycle ITIL Omschrijving Key archive Availability Management Het archiveren van sleutels Archiving moet het mogelijk maken dat een sleutel in actieve dienst kan worden teruggezet, waarmee de beschikbaarheid kan worden geborgd. De keuze om Incident Management en Problem Management niet op te nemen in de matrix is ingegeven doordat deze gerelateerd kunnen worden aan alle key life cycle activiteiten. De activiteit “het gebruik van sleutels” is geen ITIL-proces, derhalve hebben wij dit een operationele handeling genoemd. De activiteiten bij Availability Management zijn zeer nauw gerelateerd aan eisen vanuit de klant en de aan de sleutels gestelde kwaliteitseisen die uit risicoanalyses voortkomen. Indien de nieuwste versie van ITIL gebruikt zou worden, zou Availability Management opgesplitst worden in Availability Management met betrekking tot beschikbaarheid en in ITIL Security Management met alle activiteiten en kwaliteitseisen rondom integriteit en vertrouwelijkheid. In deze scriptie hebben wij er voor de overzichtelijkheid voor gekozen om onder Availability Management, beschikbaarheid te beschouwen. De activiteiten en bijbehorende normen om de ITIL processen voor key management controleerbaar te maken, worden in het volgende hoofdstuk beschreven.



Pagina 22 van 32

5 Generiek model Hieronder beschrijven wij ons generiek model, dat bestaat uit een overzicht van de gekozen ITIL-processen inclusief hun relatie met key management. Bij deze processen zijn bijbehorende normen beschreven die van toepassing zijn op key management. Omdat er bij een aantal processen sprake is van generieke beheersdoelstellingen die al randvoorwaardelijk in de uitvoering van ITIL verweven zijn, worden deze niet aangegeven. Hiervoor zijn al voldoende kaders aanwezig, waarbij we willen verwijzen naar de PI-studie Basisnormen Beveiliging en Beheer ICT-infrastructuur [BBBI] van B. Bokhorst en J. Schaping. Deze algemene processen, Incident, Problem en Change en Service Level Management worden daarom slechts kort beschreven. Configuration Management (ITIL – Service Support) Configuratiebeheer is verantwoordelijk voor het onder controle brengen en houden van de veranderende IT-infrastructuur (standaardisatie en statusbewaking); het identificeren van configuratieonderdelen (inventarisatie, onderlinge relaties, verificatie en registratie), het verzamelen en beheren van documentatie over de IT-infrastructuur en het verschaffen van informatie over de IT-infrastructuur aan alle overige processen. Dit proces is uiterst belangrijk voor key management. Zoals eerder aangegeven kenmerkt de omgeving van de Rabobank zich door een veelvoud van sleutels. Omdat wij de cryptografische dienst zien als een ICT dienst die bestaat uit diverse componenten en activiteiten, beschouwen wij de sleutel hierbij als een asset of configuratie-item. Hierdoor kan centrale registratie van de sleutel plaatsvinden in de configuratie-database en wordt automatisch aansluiting verkregen met de ITIL-processen. Opgemerkt wordt dat niet de sleutel zelf in de CMDB opgeslagen wordt, maar de meta-informatie die van belang is voor o.a. de continuïteit van de dienstverlening. Attentiepunt met betrekking tot deze vastlegging is dat deze data wel afgeschermd moeten worden op basis van “need to know”. De aspecten die onder andere vastgelegd moeten worden, zijn: sleutelnaam en -type, de relatie met de processen en andere toegepaste sleutels, het toegepaste algoritme en de sleutellengte, en de levensduur en vervaldatum van de sleutel. Hiermee voegt CM het volgende toe: -

het registreert alle sleutels en toepassingen ervan en is hiermee een centraal punt voor de overige processen; het registreert alle relaties zodat bij wijzigingen een impactanalyse kan worden uitgevoerd; indien het noodzakelijk is om een bepaald algoritme en/of de sleutellengte te vervangen, is de CMDB een belangrijk startpunt; op basis van vervaldata kan de CMDB een tijdig signaal geven om een wijziging te initiëren; de CMDB kan als ingang gebruikt worden voor (de scope van) een audit.

Normen voor key management: -

de (meta-data van) sleutels ten behoeve van de cryptografische dienst zijn centraal vastgelegd; de verantwoordelijkheden voor het muteren of opvoeren van sleutelinformatie is eenduidig belegd; toegang tot deze CMDB is alleen toegankelijk voor geautoriseerde personen en voor toegang zijn geformaliseerde procedures en autorisatiematrices opgesteld; de vastlegging sluit aan op bestaande processen, zodat gewenste vervanging tijdig gesignaleerd wordt;



Pagina 23 van 32

-

het verstrekken van actuele en/of historische informatie van de sleutelgegevens aan andere beheerprocessen; door middel van steekproeven wordt vastgesteld dat de geregistreerde sleutelinformatie overeenkomt met de werkelijkheid.

Incident Management (ITIL – Service Support) Het doel van incidentbeheer is om storingen te verhelpen en de dienst snel weer beschikbaar te hebben. Het is de ingang voor de klant en hiermee een reactieve taak. Een centrale vastlegging van een (ver)storing is belangrijk voor key management. Hiermee wordt een single point of contact verkregen, zodat het voor alle partijen binnen de Rabobank duidelijk is waar zij problemen met key management kunnen melden. Op basis van die informatie kan een verstoring geclassificeerd worden op prioriteit, gevolgd worden, gematcht worden aan eerdere incidenten (de zgn. known errors) en eventueel geëscaleerd worden. De rapportage van IM kan als input voor andere processen of ten behoeve van onderzoek naar een oorzaak worden toegepast. Incidenten ten aanzien van key management zijn: het vermoeden dat een sleutel gecompromitteerd is; een melding dat de dienst niet in overeenstemming met de afspraken verloopt (een bericht wordt niet encrypt); een verzoek tot herstel van een sleutel. Problem Management (ITIL – Service Support) Bij een vermoeden dat er structureel iets mis is met de cryptografische dienst, zal Probleem Management trachten de oorzaak te achterhalen. Kern van deze dienst is het opsporen, vastleggen, volgen en oplossen van structurele incidenten. Om dit effectief te kunnen uitvoeren is een nauwe relatie met de andere processen noodzakelijk. In relatie tot key management van cryptografie betekent dit: het regelmatig uitvallen van sleutels, bijvoorbeeld als gevolg van temper-resistance apparatuur; het regelmatig uitvallen van cryptografische hard- en softwarecomponenten kan leiden tot het terugbrengen van de eerder vastgestelde levensduur; in geval van problemen moet een beperkte groep personen de mogelijkheid hebben om herstel (recovery) van sleutels uit te voeren. Change Management (ITIL – Service Support) Het gecontroleerd doorvoeren van wijzigingen in de cryptografische dienst. Het doel is om negatieve invloeden door wijzigingen in de dienst en daarmee gepaard gaande onbeschikbaarheid van informatie voor de organisatie te voorkomen. Van de wijziging kan de impact worden vastgesteld en afhankelijk van deze impact dient expliciete toestemming verkregen te worden. Voor key management kunnen wijzigingen voortkomen uit: de oplossing van problemen; nieuwe producten, diensten of apparaten; het verstrijken van de vervaldatum en/of levensduur van sleutels; interne of externe voorschriften; voortschrijdend inzicht, onder andere door risicoanalyses, bijvoorbeeld als voorzien wordt dat een bepaald algoritme of een bepaalde sleutellengte binnen afzienbare tijd niet meer voldoende is; het intrekken van sleutels die bijvoorbeeld gecompromitteerd zijn. Teamnummer Auteur(s) Datum Versie


Pagina 24 van 32

Release Management (ITIL – Service Support) De oude ITIL benaming van dit proces is Software Control & Distributie, die vooral gericht is op de programmatuur. Release Management voert het beheer en de distributie van programmatuur en apparatuurversies die in gebruik zijn en door de beheerorganisatie worden ondersteund. Dit zijn dus alle activiteiten die met betrekking tot de levenscyclus van sleutels worden verricht en via een change worden geregistreerd. Andere activiteiten zijn: het plannen van de uit te voeren activiteiten; het testen van cryptografische hardware, software en sleutels; het distribueren van cryptografische hardware, software en sleutels; het plaatsen van hardware (apparaten) ten behoeve van het betalingsverkeer. Normen voor key management: Bij het uitvoeren van sleutelhandelingen zijn er richtlijnen ten aanzien van vertrouwelijheid en beschikbaarheid: -

-

bij het (proces van) distribueren van sleutels is een toezichthouder als Interne Controleur aanwezig die de activiteiten volgt en vastlegt; sleutels mogen nooit in klare waarden buiten een hardware device voorkomen. Ze mogen -onder strikte functiescheiding- wel encrypt onder een andere sleutel of in gescheiden delen voorkomen; sleutels mogen slechts voor één activiteit worden toegepast; sleutels in een productieomgeving mogen niet in andere omgevingen (test en/of acceptatie) voorkomen; sleutels worden gecontroleerd overgedragen tussen de omgeving waarin ze gecreëerd en geïnstalleerd worden; sleutels mogen niet -buiten de daarvoor bestemde processen (opdrachten) omgewijzigd worden; sleutels die vernietigd moeten worden, worden in alle aanwezige vormen vernietigd.

Availability Management (ITIL – Service Delivery) Availability Management heeft als hoofddoelstelling het beschikbaar stellen en houden van de ICT-dienstverlening volgens de daarvoor overeengekomen afspraken die zijn vastgelegd in service level agreements. Voor key management houdt dit in dat er via service level agreements afspraken zijn gemaakt over de handelwijze indien sleutels verloren en/of verlopen, dan wel niet meer actief zijn. Normen voor key management: De in een service level agreements afgesproken kwaliteitseisen worden door middel van een risicoanalyse op haalbaarheid geanalyseerd; -

-

eisen aan de cryptografische dienst en de sleutels worden, na goedkeuring van klant en cryptografische dienstverlener, opgenomen in de CMDB; back-up van een sleutel vindt, afhankelijk van de verschijningsvorm, plaats bij generatie van de sleutel (als de sleutel in afzonderlijke delen wordt aangeleverd) of via het generieke back-up proces van de organisatie (als de sleutel versleuteld in de software is opgeslagen); de aparte sleuteldelen dienen opgeborgen te zijn in aparte kluizen die op basis van functiescheiding benaderd mogen worden door verschillende functionarissen; de risicoanalyses en gestelde kwaliteitseisen aan de sleutels zijn opgenomen in de functionele en technische architectuurdocumenten en eventuele wijzigingsvoorstellen;



Pagina 25 van 32

-

-

-

conform risicoanalyses of afgesproken service level agreements worden sleutels vernietigd of verloopt de bruikbaarheid van de sleutels. (er is een tijdslimiet ingesteld); indien encrypte gegevens bewaard blijven en de actieve sleutel niet meer operationeel is, zal deze sleutel gearchiveerd worden met duidelijke vermelding van actieve levensduur; de eisen aan archivering zijn gelijk aan de eisen die aan de productionele omgeving worden gesteld; de gearchiveerde sleutel mag nooit terugkeren in de operationele fase.

Service Level Management (ITIL – Service Delivery) Dit proces staat aan de basis van de kwaliteit van de dienstverlening en vormt de koppeling met de Service Support. Hier worden afspraken gemaakt met klanten en leveranciers. Deze afspraken over de (eisen aan) de dienstverlening worden vastgelegd in een Service Level Agreement, die als norm voor een audit kan worden toegepast.



Pagina 26 van 32

6 Conclusie Key management heeft al een generiek model, de key life cycle, waarvoor een groot aantal normenkaders van diverse instanties zoals overheden en leveranciers aanwezig zijn. Met toevoeging van de relevante ITIL-processen ontstaat naar onze mening een duidelijke toegevoegde waarde. Naast de operatie kan nu ook het proces volgens bestaande richtlijnen uitgevoerd worden. De synergie tussen deze modellen maakt dat de auditability groter wordt. Ook voor ITIL zijn de normenkaders volop aanwezig. Op basis van deze audit kan vervolgens met een generieke verklaring het key management proces ‘in control’ verklaard worden. Onze onderzoeksvraag was: Is het mogelijk om een generiek model te definiëren waarmee een ‘in-control statement’ voor het proces “key management (KM)” kan worden afgegeven? Tijdens ons onderzoek hiernaar hebben we de key life cycle tegenover de ITIL-processen uitgezet. Doel hiervan was de ITIL-processen in relatie te brengen met het key life cycle model. Wij verwachtten tot een nieuw model te kunnen komen dat generiek zou zijn omdat er gebruik wordt gemaakt van andere generieke modellen. Met het uitzetten van een matrix kwamen we erachter dat er een aantal ITIL-processen zijn die een toegevoegde waarde hebben voor de verschillende fasen van de life cycle. Deze relevante ITIL-processen hebben we nader uitgewerkt in relatie tot de fase van de key life cycle. Door deze relatie tussen de procesmatige benadering en de beheeractiviteiten ontstaat een hoger niveau van beheer, dat gekwalificeerd mag worden als nieuw generiek model. Hiermee kunnen we de onderzoeksvraag dus positief beantwoorden. De voordelen die de samenvoegingen van de standaarden leveren, bieden naar onze mening voldoende perspectief om key management met behulp van ITIL in te richten, waarmee het concreter meetbaar is voor auditors. Zij kunnen hierdoor aan het management en de directie een ‘in-control statement’ afgeven omtrent het beheer van de cryptografische diensten. Dit kan een voordeel opleveren indien (delen van) het beheer van deze cryptografische dienst uitbesteed wordt. Hiermee kan een groot deel van de problematiek van de Rabobank worden opgelost. Met het instellen van een taak of rol als key manager wordt een centraal punt gecreëerd. De kennis en verantwoordelijkheden worden hiermee eenduidig belegd. Met het toepassen van de genoemde ITIL-processen wordt een aansluiting op alle benodigde processen en partijen verkregen. Hoewel alle aangegeven processen hierbij van belang zijn, is vooral het registreren van de informatie van de sleutels een belangrijk aspect, omdat er veel diversiteit in dit vakgebied is en de sleutelhandelingen niet altijd frequent plaatsvinden. Voor elke omgeving waarvoor key management wordt uitgevoerd, moet per fase van de key life cycle de bijbehorende AO/IC worden ingericht. Dit kan plaatsvinden op basis van (ISO-)normen die voor elk van deze fasen zijn vastgesteld. Hierbij hoeven niet per se alle key management activiteiten door de key manager zelf uitgevoerd te worden. Wel dient deze altijd betrokken te zijn bij de operatie. Een voorbeeld hiervan is het invoeren van sleutels die door een andere partij worden aangeleverd. Deze actie wordt aangemeld bij de key manager en daarna uitgevoerd door (applicatie)beheerders. Bij deze invoer is de key manager toezichthouder die de uitgevoerde activiteiten vastlegt. Als de key manager zelf een activiteit uitvoert, ligt het toezicht bij de afdeling Informatie Beveiliging. Deze afdeling zal ook de tactische key management aspecten, zoals toekomstige wijzigingen van algoritme en/of sleutellengte, bewaken en indien nodig initiëren. Teamnummer Auteur(s) Datum Versie


Pagina 27 van 32

Met deze inrichting kunnen naar onze mening de continuïteit en vertrouwelijkheid van key management gewaarborgd worden. Door de inrichting van de processen zoals deze zijn omschreven kan het gehele key management proces eenvoudig geaudit worden en op basis daarvan ‘in control’ verklaard worden.



Pagina 28 van 32

Bijlage A. Afkortingen & Definities AES CA CI of ci CO of co COBIT COSO Cryptografie DES DNB EFF ICT ISACA ITIL ISO KM PKI ROB RSA SAS70 SOx TTP


Advanced Encryption Standard; encryptiealgoritme. Certificate Authority; Een vertrouwde instantie (TTP) die publieke sleutels certificeert, certificaten publiceert en certificaten intrekt. Configuration item. Een component van de ICT-infrastructuur. Control Objectives. Control Objectives For Information and Related Technology. Een raamwerk voor het gestructureerd inrichten en beoordelen van een IT-beheeromgeving, gebaseerd op best practices. Committee of Sponsoring Organisations (COSO) of the Treadway Commission. COSO bevat aanbevelingen en richtlijnen ten aanzien van interne controle en interne beheersing. Cryptografie is de wetenschap die zich in de meest algemene zin bezighoudt met methoden voor beveiliging van opslag en transport van data. Data Encryptie Standard; encryptiealgoritme. De Nederlandsche Bank, toezichthouder voor alle Nederlandse banken. Electronic Frontier Foundation; Amerikaanse organisatie die zich bezighoudt met privacy en burgerrechten. Informatie en communicatie technologie. Het geheel van hardware en software (incl. databases) componenten waarmee informatie door geautomatiseerde systemen bewerkt en getransporteerd kan worden. Information Systems Audit and Control Association; beroepsvereniging voor IT-verwante professionele betrekkingen. IT Infrastructure Library; generiek referentiekader voor het inrichten van een ICT-organisatie. International Organization for Standardization; internationale organisatie die normen vaststelt. Key Management / sleutelbeheer. Public Key Infrastructure; een systeem waarmee uitgiften en beheer van digitale certificaten kan worden gerealiseerd. Regeling Organisatie en Beheersing; voorgeschreven kader van DNB voor de Nederlandse banken voor de organisatie en beheersing van activiteiten. Rivest Shamir en Adleman; asymmetrische versleuteling, genoemd naar de uitvinders. Statement on auditing standards (SAS no. 70) http://www.sas70.com; standaard rapportagemethode. Sarbanes Oxley Act; Amerikaanse wet ter voorkoming van boekhoudfraude. Trusted Third Party; een vertrouwde onafhankelijke partij die diensten aanbiedt die de betrouwbaarheid van elektronische gegevensuitwisseling en gegevensopslag vergroten.


Pagina 29 van 32

Bijlage B. Literatuurlijst [AICPA] [BBBI] [CIOPL]

Service Organizations: Applying SAS No. 70 PI-studie Basisnormen Beveiliging en Beheer ICT-infrastructuur CIO platvorm, werkgroep Informatiebeveiliging, 2006, Informatiebeveiliging In Control [COBIT] Control Objectives For Information and Related Technology; Versie 4. [COSO] Enterprise Risk Management Framewrok, Executive Summary, draft-versie. http://www.erm.coso.org [CRYPT1] Praktijkreeks informatiebeveiliging; Cryptografie in de praktijk; ISBN 9044000470 [CRYPT2] Technische beveiligingsstudie encryptie, Platform Informatiebeveiliging, werkgroep encryptie, Uitgeverij Lemma BV, Utrecht, 2002, ISBN 9059311132 [CRYPT3] Netwerkbeveiliging en cryptografie, W. Stallings, Uitgeverij Academic Service, Schoonhoven, 2000, ISBN 9039511055 [CRYPT4] Smartcards in de reële en virtuele wereld, JW Rietman en FA Spoelstra, Uitgeverij Ten Hage en Stam, Den Haag 2001, ISBN 9044002422 [DRIES] Jan Driessen, Reinier Kamstra, Arie Molenkamp, 2003, In Control Statements, http://www.auditing.nl [EDPAU] Handboek EDP-auditing – afl 10 (juli 1995) [GROND] Grondslagen IT-auditing, R. Fijneman, E. Roos-Lindgreen, P. Veltman, Academic Services, ISBN 9039522979 [ISF] International Security Forum. Diverse rapporten omtrent cryptografische diensten. http://www.securityforum.org [ISO11568] ISO 11568_2 Banking key management [ITES] Pink Elephant Education & Development BV, ITIL Essentials [ITSMF] ITSMF, Lex Hendriks, IT Service management, een introductie, 2000. (http://www.itsmf.nl) [ITSM] ITIL Security Management; The Stationery Office; ISBN 011330014x [ISACA] Information Systems Audit and Control Association; http://www.isaca.nl/index.htm [KPMG] KPMG Risk and Advisory Services, Key Management Policy and Practices Framework; January 2002 [LUBBE] dr.ir. J.C.A. van der Lubbe, 1994, Basismethoden Cryptografie, Delftse Uitgevers Maatschappij, ISBN 90-6562-139-3 [ONTWE] Het ontwerpen van een onderzoek, P. Verschuren, H. Doorewaard, Uitgeverij Lemma, ISBN 9051897073 [OTTEN] Drs. Jan Otten, Bestuur dat zegt u nu wel, maar…? (waarde van ICS), Auditing.nl [ROB] Regeling Organisatie en Beheersing, Handboek WtK 2004, DNB [SAS70] Statement on Auditing Standards number 70 [SCHNE] Bruce Schneider, 1996, Applied Cryptography, John Wiley & Sons, ISBN 0471117099 [TABAK] Code Tabaksblat WIKIPEDIA http://www.wikipedia.nl [WUNNI] S. van Wunnik, In Control, http://www.auditing.nl



Pagina 30 van 32

Bijlage C. Geïnterviewden M. Butterhoff RE BC AJM Janssen-Steenbergen BC Jeursen, BC D. ‘t Jong CISSP Mr WHF Hafkamp L. Scholte Dr. A. Shahim RE Drs. O. Keegel


IT-auditor KPMG Control&Compliance Rabobank Nederland Operationeel Risico Management Rabobank Nederland Informatie Security Officer Rabobank Nederland Programmamanager Informatie Beveiliging Rabobank NL Security Officer, Equens IT-auditor KPMG STV translations


Pagina 31 van 32

EEN GENERIEK MODEL VOOR EEN IN-CONTROL STATEMENT BIJ KEY MANAGEMENT

Recommend Documents