Technical Compliance van systeemsettings

Technical Compliance van systeemsettings Controlling the systemconfiguration

VRIJE UNIVERSITEIT VAN AMSTERDAM 1 oktober 2010 Opgesteld door: Mustan Kurt, Mili Hadziomerovic

Technical Compliance van systeemsettings Controlling the systemconfiguration

Titelblad Studenten Naam

: ing. M (Mustan) Kurt

ing. M (Mili) Hadziomerovic

Studentnummer

: 1689932

1787462

Teamnummer

:1014

1014

Telefoonnummer

: +31 618 68 0982

+31 639 54 9778

E-mail

: [email protected]

[email protected]

Organisatie

: Wolfit - IT Security Professionals

Duijnborgh Audit b.v.

Begeleiders Begeleider VU

: dhr. Kees Van Hoof

Bedrijfscoach

: dhr. Frank Kossen

Versie Titel document

: 1014_Technical_compliance_Kurt_Hadziomerovic.pdf

Versie document

: 1.0

Status

: Final

VU Amsterdam Postdoctorale IT Audit opleiding Utrecht, 1 oktober 2010

INHOUDSOPGAVE 1

2

3

4

5

6 7

INLEIDING ....................................................................................................................................2 1.1 AANLEIDING .........................................................................................................................2 1.2 SAMENHANG ONDERZOEK EN HET VAKGEBIED IT AUDITING ..........................................................2 1.3 PROBLEEMSTELLING ..............................................................................................................3 1.4 DOELSTELLING VAN HET ONDERZOEK ........................................................................................3 1.5 DE SCOPE VAN HET ONDERZOEK...............................................................................................4 1.6 DE METHODE VAN HET ONDERZOEK..........................................................................................4 1.7 OPBOUW VAN HET ONDERZOEK ...............................................................................................4 THEORETISCH KADER: TECHNISCHE COMPLIANCE VAN SYSTEEMSETTINGS................................................6 2.1 BEGRIP COMPLIANCE .............................................................................................................6 2.2 BEGRIP SYSTEEMSETTING ........................................................................................................7 TOTSTANDKOMING VAN SYSTEEMSETTINGS .......................................................................................9 3.1 TOP-DOWN MODEL ...............................................................................................................9 3.2 POLICY, STANDAARDEN EN PROCEDURES ................................................................................ 10 3.2.1 POLICY ..................................................................................................................... 11 3.2.2 STANDARDS .............................................................................................................. 11 3.2.3 PROCEDURES............................................................................................................. 12 3.3 SAMENVATTING EN CONCLUSIE............................................................................................. 14 RANDVOORWAARDEN TECHNISCHE COMPLIANCE ............................................................................ 15 4.1 CONTROLS OP BESTURINGSSYSTEEMNIVEAU............................................................................ 15 4.2 IT GENERAL CONTROLS EN SYSTEEMSETTING .......................................................................... 16 4.2.1 IT-BEHEERSPROCESSEN ............................................................................................... 16 4.3 CONTROL PROCES .............................................................................................................. 17 4.4 SAMENVATTING EN CONCLUSIE............................................................................................. 18 COSO EN COBIT ....................................................................................................................... 19 5.1 WAT IS COSO? ................................................................................................................. 19 5.1.1 BRUIKBAARHEID VAN COSO VOOR DE BEHEERSING VAN DE TECHNISCHE COMPLIANCE .......... 21 5.2 WAT IS COBIT? ................................................................................................................. 22 5.2.1 BRUIKBAARHEID VAN COBIT VOOR DE BEHEERSING VAN DE TECHNISCHE COMPLIANCE........... 23 5.3 SAMENVATTING EN CONCLUSIE............................................................................................. 26 ANALYSE INTERVIEW RESULTATEN ................................................................................................. 27 CONCLUSIE ............................................................................................................................... 28 7.1 AANDACHTSGEBIEDEN IT-AUDITOR ....................................................................................... 29

BIJLAGE I: LITERATUURLIJST…………………………………………………………………………………………………….. 30 BIJLAGE II: FIGURENLIJST…………………………………………………………………………………………………………. 31

Voorwoord De laatste toets voor de studenten aan de Postgraduate IT Audit opleiding aan de Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) van de Vrije Universiteit te Amsterdam is het doen van een onderzoek gerelateerd aan het vakgebied IT Auditing. In het kader van deze toets hebben wij, Mustan Kurt en Mili Hadziomerovic, een onderzoek uitgevoerd. De resultaten van ons onderzoek zijn vastgelegd in de voor u liggende scriptie. Organisaties moeten steeds vaker voldoen aan eisen vanuit weten regelgeving. Door het implementeren van maatregelen om te kunnen voldoen aan deze eisen wordt door organisaties grote investeringen [Leenslag 2007] gedaan om de IT-omgeving zodanig in te richten zodat hieraan wordt voldaan. Een voorbeeld hiervan is de implementatie van SOx controls, deze is verplicht voor iedere onderneming geregistreerd aan een Amerikaanse beurs. De aandacht hiervoor heeft geleid tot standaardisering en uniformering van procedures en werkwijzen binnen (IT-)organisaties [Leenslag 2007]. Het voldoen aan onder andere weten regelgeving wordt ‘compliance’ genoemd. In onze scriptie zullen wij dieper ingaan op de betekenis van compliance en dan in het bijzonder de relatie die het met techniek heeft. De centrale vraagstelling voor dit onderzoek luidt: “Op welke wijze kan de technische compliance van de systeemsettings op een serverplatform de mate van de effectiviteit en de efficiëntie van (technical) audits verhogen?”

Deze scriptie kon alleen tot stand komen dankzij de welwillende medewerking van een aantal personen, die we via deze weg nogmaals willen bedanken. Een woord van dank gaat op de eerste plaats uit naar onze scriptiebegeleiders Kees van Hoof en Frank Kossen voor de tijd die zij genomen hebben om ons tijdens de scriptieperiode te begeleiden en te motiveren. Daarnaast willen we de volgende personen danken voor hun kennisdeling en medewerking: • • • • • •

Janwillem Kok – Security Architect Infrastructure (Microsoft) Guido Bezemer – Security Consultant (LARGOS) Carlo Seddaiu – Sr. Security Specialist Unix (SOLICT) Walter Meeus - Sr. Security Specialist Mainframe (ING) Bert Rechter – Information Risk Manager (Shell) Erik de Vries – Department Head Group Audit Services & TB/IT (ABN AMRO)

Utrecht, oktober 2010

Mili Hadziomerovic Mustan Kurt

Technical Compliance van systeemsettings | 1-10-2010

Voor het uitvoeren van dit onderzoek hebben wij literatuur geraadpleegd en daarnaast een aantal personen uit het bedrijfsleven geïnterviewd. De output van de interviews heeft ons de nodige informatie en verschillende inzichten opgeleverd om een helder beeld over dit onderwerp te kunnen vormen.

1

1

Inleiding

De scriptie die voor u ligt is een uitwerking en weergave van het door ons uitgevoerd onderzoek ter afsluiting van de postdoctorale IT Audit opleiding die wij gevolgd hebben aan de Vrije Universiteit te Amsterdam. In dit hoofdstuk is het kader van het onderzoek geschetst. Hierin is beschreven wat voor ons de aanleiding is geweest om dit onderzoek uit te voeren en welke probleemstelling wij hierin onderkennen.

1.1 Aanleiding Kort onderzoek op het internet leert ons dat sinds de ‘Enron1’ affaire en daarop volgende boekhoudschandalen veel organisaties te maken hebben gekregen met extra weten regelgeving die van toepassing is op hun IT-omgeving, zoals bijvoorbeeld SOx. Gebruikte technieken om te voldoen aan deze weten regelgeving in de IT-omgeving worden steeds complexer en zijn vaak moeilijk te beheren en daarnaast voor de IT-auditor moeilijk te beoordelen. Om het beheer en de controleerbaarheid te verbeteren investeren [Leenslag 2007] organisaties om hun serverplatformen zodanig in te richten dat voldaan wordt aan de toepasselijke weten regelgeving en de interne eisen vanuit de organisatie zelf (business-demands). Dit heeft in de praktijk geleid tot een standaardisering en uniformering van procedures en werkwijze van de (IT-)organisaties [Leenslag 2007]. Een trend lijkt te zijn dat organisaties zelf methodieken bedenken om óók op het gebied van de techniek te kunnen voldoen aan weten regelgeving en de interne regels. De modellen en methodieken die door organisaties worden gebruikt zijn echter zeer divers.

De bovengenoemde vaststellingen zijn voor ons de aanleiding geweest om te onderzoeken hoe de gebruikte methodieken in de IT-omgeving om te voldoen aan bepaalde eisen, de mate van de efficiëntie en effectiviteit van audits kunnen verhogen.

“The approach to audit and compliance must be recognized as an integral part of an organization’s business processes. The emphasis of a compliance solution must shift from auditing what has already occurred to automatically detecting and preventing violations before they happen.”……….”Standards should be the basis for auditing to reduce the cost and gain a return on investment from compliance audits.” [ISACA 2009]

1.2 Samenhang onderzoek en het vakgebied IT Auditing De aanleiding voor dit onderzoek geeft aan dat organisaties investeringen doen om hun IT-omgeving zodanig in te richten dat er voldaan wordt aan bepaalde weten regelgeving (interne en externe).


Mustan Kurt is vanuit een rol als security officer bij één van zijn opdrachtgevers zelf betrokken geweest bij het opzetten van een control proces dat er op toeziet dat de instellingen (parametrisering) van besturingssystemen worden beheerst om zo te kunnen voldoen aan het woud van regels en voorschriften (externe weten regelgeving en tevens de interne beleidsregels). Wat daarbij opvalt is dat, terwijl het op zichzelf al een enorme opgave is om te voldoen aan weten regelgeving, het voor de IT-beheerorganisatie een vrijwel onmogelijke opgave blijkt om te zorgen dat systemen en applicaties zodanig zijn ingericht dat gesproken kan worden van compliance van de ITomgeving.

1 Bedrijf dat ten onder ging aan een boekhoudschandaal [http://nl.wikipedia.org/wiki/Enron]

2

Het resultaat van deze investeringen zijn vaak controlemechanismen die organisaties helpen hun ITomgeving onder controle te houden, zodat voldaan wordt aan vigerende eisen. De vraag is hoe deze controlemechanismen de IT-auditor kunnen helpen om audits effectiever en efficiënter uit te voeren. Deze scriptie is geen beoordeling van een casus die betrekking heeft op het interne beheersingsproces rondom de gebruikte controlemechanismen voor de interne beheersing van de IT-omgevingen. De scriptie beoogt de IT-auditor te voorzien van achtergrondinformatie waarin de aandachtspunten liggen bij de beoordeling van de technische compliance van serverplatformen. Daarnaast worden de delen van COSO2 en CobIT3 die bruikbaar zijn voor het technical compliance gedeelte toegelicht.

1.3 Probleemstelling Nu veel organisaties zelf methodieken voor het compliant zijn en houden van technical compliance bedenken en implementeren ontstaat de vraag hoe betrouwbaar en controleerbaar deze methodieken zijn. Worden de bestaande frameworks op de juiste manier gebruikt? Worden de eisen vanuit de weten regelgeving op de juiste manier vertaald naar concrete maatregelen?

1.4 Doelstelling van het onderzoek Dit onderzoek heeft als doelstelling inzicht te verkrijgen in de effectiviteit en efficiëntie van het instrumentarium om de technische compliance van de serverplatformen te sturen, te beheersen en te controleren. De doelstelling is onderzocht aan de hand van een centrale onderzoekvraag die onderbouwd is met een aantal deelvragen. De centrale onderzoeksvraag luidt:

Op welke wijze kan de technische compliance van systeemsettings op een serverplatform de mate van de efficiëntie en effectiviteit van (technical) audits verhogen?

• • • •

Wat wordt verstaan onder de technische compliance van systeemsettings op een serverplatform? Hoe kan weten regelgeving vertaald worden naar systeemsettings? Welke aspecten van de bestaande frameworks (COSO, CobIT) kunnen gebruikt worden om de technische compliance van systeemsettings te kunnen beheersen? Wat voor toegevoegde waarde kan de technische compliance van systeemsettings leveren aan de IT-auditor?

2 www.coso.org 3 www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx


Om een antwoord te kunnen geven op de centrale onderzoeksvraag zijn voor dit onderzoek viertal deelvragen geformuleerd:

3

1.5 De scope van het onderzoek Voor onze scriptie hebben we de volgende grenzen gehanteerd: • •

•

De term ‘compliance’ is door middel van literatuurstudie onderzocht en vervolgens hebben wij voor dit onderzoek een definitie van compliance die past binnen dit onderzoek vastgesteld; Tijdens het onderzoek is beperkt ingegaan op risk management en organisatiekunde om een antwoord te kunnen geven welke aspecten belangrijk zijn bij de vertaling van weten regelgeving naar systeemsetting; Voor dit onderzoek is gekeken naar COSO en CobIT om te kunnen vaststellen welke aspecten van deze twee frameworks gebruikt kunnen worden om de technische compliance van systeemsettings vast te kunnen stellen. Alle andere frameworks zijn buiten beschouwing gelaten. In hoofdstuk 5 geven we aan waarom we hiervoor hebben gekozen.

1.6 De methode van het onderzoek Dit onderzoek is voornamelijk te bestempelen als een literatuuronderzoek. Het theoretische kader van het onderzoek is opgebouwd uit de geraadpleegde literatuur. Bij het literatuuronderzoek zijn de begripsbepalingen en de theoretische modelvorming doelstelling geweest. Diverse vakbladen, zoals de EDP-Auditor, ISACA Journal en boeken over IT Auditing, Risk Management en Compliance zijn gebruikt om antwoord te kunnen geven op de onderzoeksvragen. Daarnaast is er een aantal interviews gehouden met medewerkers van (inter)nationale organisaties en met collega IT-auditors om vast te kunnen stellen op welke wijze de technische compliance de effectiviteit en efficiëntie van (technical) audits kan verhogen.

1.7 Opbouw van het onderzoek

F IGUUR 1: OPBOUW SCRIPTIE


Onderstaand figuur geeft weer hoe het onderzoek opgebouwd is.

4

Hoofdstuk 1: In dit hoofdstuk wordt de aanleiding en motivatie van het onderzoek beschreven. Daarnaast wordt het kader van het onderzoek geschetst. Hoofdstuk 2: In dit hoofdstuk wordt het theoretische kader geschetst. Het theoretische kader heeft als doelstelling de lezer duidelijk te maken wat het begrippenkader voor dit onderzoek is geweest. Eerder in dit document zijn de termen zoals compliance, systeemsettings benoemd. In hoofdstuk 2 worden deze begrippen aan de lezer verduidelijkt en daarnaast wordt de definitie van de technische compliance van systeemsettings vanuit ons perspectief voor dit onderzoek bepaald. Hoofdstuk 3: In dit hoofdstuk wordt de probleemstelling van dit onderzoek verduidelijkt. De vertaling van weten regelgeving naar concrete maatregelen is de grootste uitdaging binnen compliance. In dit hoofdstuk wordt gekeken welke aspecten van belang zijn bij de vertaling van de weten regelgeving naar de systeemsettings. Hoofdstuk 4: In dit hoofdstuk komen de randvoorwaarden aan de orde die binnen een organisatie aanwezig moeten zijn om technical compliance na te kunnen streven. Hoofdstuk 5: In dit hoofdstuk worden twee frameworks besproken, respectievelijk COSO en CobIT. Er is gekozen voor deze twee modellen omdat COSO en CobIT twee bekendste modellen zijn als het om compliance gaat. Hoofdstuk 5 beoogt de lezer een beeld te geven van de belangrijkste aspecten van deze twee modellen die een toegevoegde waarde kunnen leveren aan de beheersing van de technische compliance van de systeemsetting.


Hoofdstuk 6 en 7: In dit hoofdstuk worden de resultaten en de conclusies van dit onderzoek samengevat.

5

2 Theoretisch kader: Technische compliance van systeemsettings Veel organisaties zijn afhankelijk van informatietechnologie en eisen dat deze in hoge mate betrouwbaar is. Een systeem dat wordt onderbroken of gecompromitteerd kan leiden tot fraude, verlies van klanten, geld, data, etc. Informatietechnologie is het samenstel van mens, procedures en techniek. Belangrijk onderdeel van informatietechnologie is de technische infrastructuur, waaronder serverplatformen. Om de betrouwbaarheid van deze serverplatformen te waarborgen, dienen adequate IT-beheersingsmaatregelen getroffen te worden. Door het treffen van deze maatregelen kunnen risico’s in bedrijfsprocessen, die ondersteund worden door de automatisering, worden beperkt. Het treffen van maatregelen kan op verschillende niveaus. Waar in het kader van dit onderzoek gesproken wordt over IT-beheersingsmaatregelen, worden systeemsettings en de wijze waarop deze zorg dragen voor het verminderen van risico’s op IT-componenten bedoeld. Het is voor organisaties van belang dat systeemsettings juist zijn ingesteld en dat deze tussentijds niet ongeautoriseerd en ongecontroleerd worden aangepast, zowel door interne medewerkers, maar ook door hacking o.i.d. Dit dient aantoonbaar gemaakt te worden om daarmee te bewijzen dat voldaan wordt aan vereiste weten regelgeving en richtlijnen van de organisatie zelf.

2.1 Begrip Compliance Bij een kort onderzoek op internet en navraag bij vakgenoten over wat compliance inhoudt, blijkt al snel dat het begrip voor verschillende interpretaties vatbaar is. Zo schrijft Cheney [Cheney 2009] in zijn artikel over beveiliging van een i5/OS4 systeem dat verwarring ontstaat bij de vraag wat compliance eigenlijk is. Cheney benoemt in het artikel de vraag, maar geeft vervolgens aan dat er geen concreet en eenduidig antwoord beschikbaar is. Een schijnbaar eenvoudige vraag als: ‘Hoe zorg ik dat ik compliant ben?’, blijkt moeilijk te beantwoorden zijn. Hieronder hebben we vanuit verschillende bronnen een aantal gehanteerde definities van de term compliance nader uiteengezet. Definitie van compliance volgens Van Dale luidt:

“Compliance is het begrip waarmee wordt aangeduid dat een organisatie werkt in overeenstemming met vigerende weten regelgeving.”


Wet- en regelgeving stellen steeds hogere eisen aan de betrouwbaarheid (vertrouwelijkheid, integriteit en beschikbaarheid) van informatiesystemen. Dit vertaalt zich meestal in eisen die niet direct concreet vertaald kunnen worden naar systeemsettings. Een voorbeeld: U dient adequate maatregelen op het gebied van de logische toegangsbeveiliging te treffen! De vraag is: “Hoe vertaal je dat naar concrete systeemsettings?” Dit is een heel lastig punt omdat het van een ander abstractieniveau is. Uit ons onderzoek is gebleken dat organisaties worstelen met de vraag hoe eisen vertaald kunnen worden naar concrete maatregelen en met welke systeemsettings aan de eisen voldaan wordt. In dit hoofdstuk geven we uitleg over wat we verstaan onder compliance en systeemsettings en welke aspecten uit de interne beheersing belangrijk zijn om de technische compliance van systeemsettings in controle te houden.

4 I5/OS is een besturingssysteem gebruikt op een IBM Power system

6

Definitie van compliance volgens Handboek EDP luidt:

“Compliance is het voldoen aan de regels die aan organisatie zijn opgelegd door wetten en regelgeving, die een organisatie zichzelf oplegt, of die worden opgelegd door contractuele verplichtingen. Naast voldoen aan de regels is het ook belangrijk om de mogelijkheden te hebben dit aan te tonen.” Definitie van compliance volgens CobIT, ISO/IEC 27001:2005, ITIL luidt:

“Ensuring that the requirements of law, regulations, industry codes and organizational standards are met. This also applies to contractual arrangements to which the business process is subject, i.e., externally imposed business criteria.” In het tweede jaar van de IT Audit opleiding heeft één van de hoogleraren, de heer Paans, de volgende bewoording gebruikt bij het omschrijven van het woord compliance vanuit een IT Audit perspectief:

Bij compliance gaat het er om dat de getroffen interne controle maatregelen volledig worden gevolgd en dat deze effectief zijn. Dit impliceert dat men deze heeft laten controleren en dat op geconstateerde manco’s acties zijn ondernomen. Ook zijn geen grote gaten meer open die onacceptabele risico’s inhouden. [Paans 2007] Zoals uit vorenstaande blijkt, wordt er door verschillende bronnen op verschillende wijze uitleg gegeven aan het begrip compliance. Zo geeft het handboek EDP twee interessante uitbreidingen aan het begrip zoals Van Dale dit definieert: “… die een organisatie zichzelf oplegt, of die worden opgelegd door contractuele verplichtingen…” en “… is het ook belangrijk om de mogelijkheden te hebben dit aan te tonen...”.

De definitie die voor dit onderzoek gehanteerd kan worden hangt samen met het begrip ‘systeemsetting’. In de volgende paragraaf kijken we wat dit begrip betekent. Vervolgens worden de begrippen systeemsetting en compliance samengevoegd tot een definitie voor dit onderzoek.

2.2 Begrip systeemsetting Voor het begrip systeemsetting hebben we op het internet een klein onderzoek gedaan. Ook bij de verschillende interviews in het kader van dit onderzoek is ingegaan op de vraag wat moet worden verstaan onder systeemsettings. Onderzoek maakt duidelijk zichtbaar dat het begrip systeemsettings niet los kan worden gezien van het begrip configuratie. Wikipedia verwijst bijvoorbeeld in een ‘search’ op het woord ‘setting’ naar configuratiebestanden:

“… config-bestanden worden op computers aangewend om de samenwerking tussen verschillende software-componenten in goede banen te leiden, of om het gedrag van een programma aan te passen aan een specifieke gebruiker of apparaat. Met ander woorden: deze bestanden ondersteunen de configuratie van het computersysteem.”


Paans geeft een nog iets andere uitleg aan het begrip door een directe relatie te leggen naar de interne controle.

7

Zoals verwacht kregen we zowel vanuit ons onderzoek op internet alsook vanuit de interviews verschillende antwoorden. De definitie die het dichtst bij de onderzoeksvraag komt, werd gegeven door de Rijksauditdienst:

“De juiste inrichting van een besturingssysteem is cruciaal voor een betrouwbare werking van alle programmatuur en de integriteit van de data die op het systeem aanwezig is. Hierbij speelt de juiste instelling van parameters voor de beveiliging en integriteit tussen bijvoorbeeld het besturingssysteem, het DBMS en de netwerkprogrammatuur een belangrijke rol. Het technisch beheer en de wijzigingen op instellingen zijn essentiële aandachtspunten.” [Kazil] Uit vorenstaande paragrafen volgt de conclusie dat er geen eenduidige definities bestaan ten aanzien van de begrippen ‘compliance’ en ‘systeemsetting’. Voor dit onderzoek is het in ieder geval van belang te definiëren wat wordt verstaan onder het samenstel van de begrippen ‘technische compliance van systeemsettings’ (overigens zonder een uitspraak te doen welke begripsbepaling beter is dan een andere). Het begrip compliance kent een grote diversiteit aan definities met centrale aspecten ‘naleving’ en ‘regels’. Voor dit onderzoek hebben wij onderstaande definitie opgesteld en gehanteerd in ons onderzoek:


“Technische Compliance van systeemsettings is het inrichten van een besturingssysteem middels een samenstel van parametrisering, technisch en operationeel beheer zodat voldaan wordt aan weten regelgeving, en waarmee gezorgd wordt voor een betrouwbare werking van het technisch systeem zodat de door de organisatie geformuleerde bedrijfsdoelstellingen worden ondersteund.”

8

3 Totstandkoming van systeemsettings In dit hoofdstuk trachten wij antwoord te geven op de vraag hoe weten regelgeving vertaald kan worden naar systeemsettings op besturingssystemen. De juiste en betrouwbare werking van een besturingssysteem is voor een belangrijk deel afhankelijk van de wijze waarop systeemsettings zijn gedefinieerd en geïmplementeerd. Om antwoord te kunnen geven op de vraag hebben wij literatuur geraadpleegd en diverse interviews gehouden. Uit ons literatuuronderzoek bleek al snel dat informatie over het ‘tot stand komen’ van systeemsettings niet of heel summier is beschreven. Wel is informatie te vinden over bijvoorbeeld welke wetten van toepassing zijn binnen een organisatie en degene die invloed hebben op de IT; Uitvoering van riskmanagement om vervolgens hieraan bepaalde (IT-)controls te koppelen. Maar hoe je dit vervolgens vertaalt naar systeemsettings is niet beschreven als proces. Door het gebrek aan goede literatuur hierover hebben wij ons voornamelijk moeten concentreren op de informatie die wij uit de interviews hebben gehaald waarop wij ons vervolgens gesteund hebben. Een gangbare methode om beleid te vertalen in concrete maatregelen, is een aanpak van risicoanalyse, waarmee de risico’s worden geïdentificeerd en vertaald naar maatregelen. De methodiek is zelfs ‘verplichte kost’ als het gaat om de best practise ‘Code voor informatiebeveiliging5’. Deze is een zogenaamde ‘procesnorm’. Een organisatie moet aantonen dat zij een managementsysteem in werking heeft en houdt, waarmee risico’s worden geïdentificeerd en vertaald naar een adequate set beveiligingsmaatregelen. De maatregelen worden opgesomd in de ISO-IEC 27002. Wat opvalt, is dat er een scala aan beveiligingsmaatregelen wordt genoemd (zoals het opstellen van procedures, et cetera), echter geen enkele ervan is een systeemsetting. Organisaties zullen dus zelf de vertaalslag moeten maken vanuit strategisch naar tactisch en operationeel beleid. In de hierna volgende paragrafen zullen we hier uitvoerig op terugkomen.

In deze paragraaf wordt inzicht gegeven in de wijze waarop gekomen kan worden tot een adequate set van systeemsettings. De beschrijving zullen we doen middels een zogenaamde top-down benadering. De omschrijving begint met het bepalen van algemene principes en eindigt met de details. Dat wil zeggen dat op het hoogste niveau de strategie wordt bepaald en op het laagste niveau uitvoering wordt gegeven aan het vastgestelde beleid om daarmee de gewenste doelstellingen te behalen. Het hoogste niveau wordt strategisch niveau genoemd en het laagste niveau wordt het operationeel niveau genoemd. Daar tussenin zit een laag die tactisch niveau wordt genoemd.


3.1 Top-down model

5 officieel de ISO-IEC 27001

9

Figuur 2 laat aspecten zien die belangrijk zijn bij het tot stand komen van systeemsettings. Zo is te zien dat bijvoorbeeld wetgeving, verwachtingen van klanten en business en industriestandaarden een relatie hebben met de te stellen eisen aan ontwerpen van systemen en daarmee natuurlijk ook diens configuraties. En daarmee samenhangend weer de systeemsettings. Als wensen van klanten en bijvoorbeeld regelgeving veranderen zal deze invloed kunnen hebben op het ontwerp van systemen. Er dient daarom rekening gehouden te worden met het blijvend compliant houden van systemen. Hiervoor zal dus tijdig een risico-evaluatie uitgevoerd moeten worden om op basis daarvan passende maatregelen te treffen in lijn met compliance.

3.2 Policy, Standaarden en procedures In de hierna volgende paragrafen zullen we figuur 2 nader verklaren door per laag in het figuur relevante aspecten te beschrijven. Tevens zullen wij aan de hand van een concreet voorbeeld de lezer meenemen en bekend maken met de materie. Om mede te bepalen hoe het proces van ‘totstandkoming’ van systeemsettings in elkaar steekt wordt eerst uitleg gegeven over de betekenis van policies, standaarden en processen. Policies kunnen beschouwd worden als dwingende regelgeving die als toetsing gebruikt dient te worden bij het implementeren van richtlijnen en maatregelen. Bij standaarden is er sprake van gekozen en


F IGUUR 2: ONTSTAAN SETTINGS [S ETHURAMAN 2006]

10

vastgelegde acties met behulp van procedure beschrijvingen, die exact weergeven hoe de inrichting moet plaatsvinden.

3.2.1 Policy Op strategisch niveau bepaalt het management van een organisatie de doelstellingen en daarmee natuurlijk ook welke weg bewandeld moet worden. Zo kan het management bepalen dat moet worden voldaan aan bijvoorbeeld de SOx wetgeving. Hoewel het voor een organisatie die geregistreerd is aan de Amerikaanse beurs verplicht is te voldoen aan deze wetgeving, ligt de keuze om hiervoor maatregelen te treffen nog altijd bij het management van een organisatie. Zij zullen dus bewust de wens moeten uitspreken te willen voldoen aan de SOx wetgeving. Keuzes die op strategisch niveau worden genomen hebben grote impact op de gehele organisatie.

Voorbeeld: Klanten van een organisatie verwachten dat deze discreet met haar gegevens omgaan. Ook stelt bijvoorbeeld de wet op de privacy dat organisaties adequate maatregelen moeten treffen om klantgegevens te beveiligingen. Op basis van voorgaande zou het management van een organisatie een policy kunnen dicteren, waarin aangegeven staat dat: “…bepaalde type data alleen versleuteld over het netwerk verstuurd mag worden. “ We merken op dat hetgeen in het voorbeeld beschreven technieken productonafhankelijk is. Beleid is dus van toepassing op data, die zowel over Windows, Unix als Mainframe systemen getransporteerd wordt. Uiteraard tenzij anders overeengekomen en uitzonderingen daar gelaten.

3.2.2 Standards De middelste laag zorgt ervoor dat het beleid wat op strategisch niveau is gedefinieerd vertaald wordt op tactisch niveau. Zij is dus verantwoordelijk voor het ‘richting geven’ en ‘kader scheppen’ voor de tactische en operationele invulling van de policy. Ook schept zij hiervoor (rand)voorwaarden, onder andere door het inrichten van een beheerorganisatie. Een belangrijke taak op dit niveau is ook om ervoor te zorgen dat de operationele uitwerking afgestemd is op de bedrijfsdoelstellingen. Door het toepassen van een interne controle systeem wordt onder meer bepaald welke


Een policy is een document wat door of in opdracht van hoger management wordt geschreven en waarin voorschriften en regels zijn opgenomen waaraan voldaan dient te worden. Policies zijn veelal een vereiste om aan weten regelgeving, zoals privacy en financieel toezicht, te voldoen. Binnen organisaties wordt het tevens gezien als een mandaat vanuit hoger management naar de lagere bedrijfsonderdelen om hetgeen in de policy staat vermeld te effectueren. Een policy op het gebied van informatiebeveiliging is dus een strategisch vastgesteld document waarin op hoofdlijnen de na te streven doelen op het gebied van informatiebeveiliging worden geformuleerd en de wijze waarop deze behaald dienen te worden. Beschrijvingen op het strategisch niveau zijn over het algemeen van een vrij hoog abstractieniveau. Hierdoor kan het policy tussen verschillende platformen worden gebruikt en is het toepassen ervan niet productafhankelijk. Een configuratie of bijvoorbeeld de commando’s die op een systeem uitgevoerd dienen te worden om deze te beveiligen zal men daarom niet terugvinden in de policies.

11

controlemaatregelen getroffen dienen te worden om te kunnen beoordelen of de ITbeheersingsmaatregelen, zoals logische toegangscontrole, backup & recovery, changemanagement, etc., effectief zijn. In de praktijk zien we dat voornamelijk best practises als de ‘Code voor Informatiebeveiliging’ worden gebruikt voor het selecteren van standaarden om generieke beveiligingsrichtlijnen te kunnen opstellen. Deze richtlijnen zijn over het algemeen vrij abstract van aard en kunnen omschreven worden als platformonafhankelijk. Hierdoor worden algemeen geldende richtlijnen uitgevaardigd waarmee richting wordt gegeven aan de implementatie, invoering en operationalisering van informatiebeveiligingsbeleid [Goosens 2007]

Voorbeeld: De scope van een standaard neigt er naar om de eisen van een bepaalde technologie te specificeren. Een voorbeeld hiervan is het definiëren dat: “.. de enige aanvaardbare encryptie-algoritmen Triple DES (3DES) of Advanced Encryption Standard (AES) zijn die binnen een organisatie gebruikt mogen worden.” We merken op dat het hierboven weergeven voorbeeld kan bestaan uit specifieke laag gelegen verplichte controls die helpen het informatiebeveiligingsbeleid te ondersteunen en af te dwingen. Meer specifiek: middels bovengenoemd voorbeeld van een standaard kan op tactisch niveau worden voldaan aan het beleid dat aangeeft dat bepaalde type data alleen versleuteld over het netwerk getransporteerd mag worden. Standaarden kunnen dus helpen om de beveiligingssamenhang binnen onderneming zeker te stellen.

Risicoanalyse binnen het kader van informatiebeveiliging is het proces van het begrijpen van de risico’s die samenhangen met bedrijfsprocessen en de ondersteunende informatiesystemen, zodat passende maatregelen gedefinieerd kunnen worden waarmee een voor de organisatie aanvaardbaar beveiligingsniveau wordt gerealiseerd [Rutkens 2009]. De te treffen maatregelen worden bepaald vanuit de behoeften die organisaties hebben, merk op dat dit ‘top down’ verloopt [Vries 2002]. Deze benadering wordt ook wel de risicoanalyse benadering genoemd. Het doel is het creëren van een minimum beveiligingsbaseline dat van toepassing is op alle informatiesystemen en IT-infrastructuren binnen alle organisatieonderdelen [Goosens 2006].

3.2.3 Procedures De behoefte op operationeel niveau bestaat uit een vertaling van de normen (het beleid) naar systeemspecifieke settings. In de door ons onderzochte bedrijven zagen wij dat gebruik gemaakt werd van een operationeel implementatieplan (tevens baseline) voor de diverse IT-systemen. Een procedure omschrijft het proces dat wordt gevolgd om aan de eisen van beleid en standaard te kunnen voldoen. Een procedure is de concrete stap-voor-stap beschrijving die gevolgd dient te


Wat voor de ene organisatie een aanvaard niveau van beveiliging is, hoeft niet voor de ander te zijn. Een standaard oplossing binnen de informatiebeveiliging zijn wij niet tegengekomen. Dit komt mede doordat organisaties zich in verschillende situaties bevinden. Dit betekent dat ook bedreigingen en risico’s per organisatie kunnen verschillen. Voor het afdekken van bedreigingen en risico’s dienen dus passende beveiligingsrichtlijnen en -maatregelen getroffen te worden. Nu zult u zich afvragen hoe deze richtlijnen en maatregelen bepaald moeten worden. Hierbij valt de term risicoanalyse. Bij het selecteren van beveiligingsrichtlijnen zal gekeken worden naar de aanwezige risico’s.

12

worden om vigerend beleid en standaard op technisch niveau te kunnen implementeren. Het implementatieplan waarin de beveiligingsmaatregelen zijn opgenomen zijn over het algemeen vrij specifiek, daar deze juist wel technologie-, product-, situatieafhankelijk zijn. In de ‘procedure laag’ zullen de abstracte beveiligingsrichtlijnen naar concrete procedures vertaald moeten worden. Door deze vertaalslag zou in deze fase ook bekend moeten worden wat de configuratie van het systeem en daarmee systeemsettings dient te worden. Wegens de technische aard van deze beveiligingsmaatregelen ligt over het algemeen de voornaamste verantwoordelijkheid voor het daadwerkelijk opstellen en implementeren van de beveiligingsmaatregelen bij het ICT personeel. Zoals ook in de aanleiding van deze scriptie beschreven, kijken techneuten meestal puur naar techniek. Alignment met beleid en standaarden is in organisaties een zorgpunt [JWKOK 2010]. Het punt wat wij middels onze scriptie willen maken is dat het totstandkomen van systeemsettings in lijn moet zijn met het informatiebeveiligingsbeleid en informatiebeveiligingsrichtlijnen. Het ontwerp van de configuratie ofwel de parametrisering van de systeemsettings is een taak die logischerwijs belegd zou moeten zijn bij de systeemengineer. Vervolgens zal die bij het opstellen van het implementatieplan (in relatie met ons onderzoek gericht op systeemsettings de configuratiebaseline) ervoor zorgen dat deze in lijn is met de minimale standaarden die worden voorgeschreven. Als de organisatie heeft voorgeschreven dat minimaal 3DES encryptie gebruikt dient te worden bij het transporteren van data over het netwerk, dan zal de engineer deze eis moeten specificeren naar een product en ervoor moeten zorgen dat het betreffende systeem 3DES gebruikt. De engineer kan bij het opstellen van een configuratiebaseline gebruikmaken van hulpbronnen, zoals handboeken, adviezen van deskundigen, de samensteller van de policy/standaard, publicaties van deskundigen, productspecificaties [Oud 2007]. Daarnaast raden wij aan de volgende hulpbronnen te raadplegen: SANS Reading room; ISACA publications; NIST publications; Overheidspublicaties; Praktijkvoorbeelden.

Voorbeeld: Het aanzetten van 3DES encryptie op een systeem. Het aanzetten van encryptie kan een vereiste zijn vanuit wetgeving*. Naast alleen het aanzetten van encryptie zou ook nagedacht moeten worden over de technische invulling van de implementatie, bijvoorbeeld de wijze waarop sleutels bewaard en uitgewisseld worden (key-exchange). Al deze aspecten kunnen vertaald worden naar een systeemconfiguratie met systeemsetting. In een implementatieplan zal beschreven moeten worden welke setting aan/uit en welke waarde een setting dient te hebben. (*) Niet alleen is encryptie vaak gewenst, het wordt in bepaalde gevallen ook gestimuleerd of zelfs verplicht door de overheid. Daarbij moet in eerste instantie gedacht worden aan de Wet Persoonsregistraties: "De houder draagt zorg voor de nodige voorzieningen van technische en organisatorische aard ter beveiliging van een persoonsregistratie tegen verlies of aantasting van de gegevens en tegen onbevoegde kennisneming, wijziging of verstrekking daarvan." Bij een hoog risico op onbevoegde kennisneming kan hieruit een verplichting tot gebruik van encryptie voortvloeien [Koops-Bautz 1995].


• • • • •

13

3.3 Samenvatting en conclusie Om de voorgaande paragrafen samen te vatten hebben we onderstaand ‘Figuur 3: ontstaan van settings(2)’ opgenomen. Deze illustreert de relatie tussen policies, standaarden en procedures. De figuur is in piramidevorm opgesteld en laat duidelijk zien dat hoe lager in de piramide des te meer in detail wordt ingezoomd ofwel aandacht wordt geschonken aan configuratie en daarmee ook de settings. Ook zijn op lager niveau de documenten meer aan verandering onderhevig. Bijvoorbeeld omdat diverse systemen nu eenmaal andere technische implementaties van beveiliging hebben. Active Directory op het Windows platform werkt nu eenmaal anders dan de beveiliging op een UNIX platform. Gezegd kan worden dat policies een algemeen en breed karakter hebben en niet vaak wijzigen. Standaarden zijn wat meer concreet en ook meer onderhevig aan wijzigingen. Procedures zijn heel gedetailleerd en zouden frequent gewijzigd kunnen worden bij het implementeren van nieuwe producten en zelfs bij het gebruik tussen de diverse platformen.

In dit hoofdstuk hebben we antwoord proberen te geven op de deelvraag: Hoe kan weten regelgeving vertaald worden naar systeemsettings? Uit onderzoek blijkt dat men uit weten regelgeving niet in detail kan vinden hoe men een besturingssysteem dient te configureren. Wet- en regelgeving schrijft echter wel voor dat voorzieningen van technische en/of organisatorische aard getroffen dienen te worden. Deze aspecten zijn over het algemeen abstract beschreven waardoor deze moeilijk vertaalbaar zijn naar een systeemsetting. Belangrijk, en dit hebben wij ook uit het onderzoek geconcludeerd, is de wijze waarop settings tot stand komen. Bovenstaande samenvatting doet vermoeden dat het nogal wat tijd en werk kost om op organisatieniveau ervoor te zorgen dat de enterprise architectuur van een systeem veilig en conform policies en standaarden is geïmplementeerd. Meest belangrijkst om te onthouden is dat op strategisch niveau zaken algemeen zijn en dat deze pas in de procedures expliciet, to-the-point en gemakkelijk te begrijpen gemaakt worden. Bijvoorbeeld: log in met uw credentials op server [servername], ga vervolgens naar pagina instellingen en zet hier het vinkje aan voor het gebruik van ‘SSL’.


F IGUUR 3: ONTSTAAN VAN SETTINGS (2)[ CODEIDOL . COM 2009]

14

4 Randvoorwaarden Technische Compliance In hoofdstuk 3 hebben we uitleg gegeven over de wijze waarop systeemsetting tot stand (kunnen) komen. De wijze waarop de technische compliance van de systeemsettings verankerd is binnen een organisatie is afhankelijk van haar omvang en de risico’s, zogenaamde compliance risico’s. Om te kunnen onderzoeken of de technische compliance met bestaande frameworks (COSO, CobIT) beheerst kan worden en wat wij onder de technische compliance verstaan, hebben wij naast het ontstaan van settings ook gekeken naar de volgende zaken: • •

•

Sterkte van controls op het niveau van een besturingsysteem; IT-beheerprocessen die van belang zijn om het gewenste niveau van technische compliance van systeemsettings te handhaven (belangrijkste beheersprocessen hebben we in de volgende deelhoofdstukken beschreven); Aspecten van een control proces die belangrijk zijn bij het beheersen van technische compliance.

F IGUUR 4: STERKTE VAN CONTROLS [P AANS 2007]

‘Figuur 4: sterkte van controls’ hierboven geeft aan dat op verschillende niveaus controls geïmplementeerd kunnen worden. De keuze om voor een bepaalde controle te kiezen heeft invloed op de effectiviteit van een controle. In het figuur komt naar voren dat op een lager niveau de controls effectiever zijn. Hierboven wordt het punt ‘controls in operating system’ genoemd, voor het gemak en consistentie met onze scriptie zullen wij het woord besturingssysteem aanhouden. De systeemsettings in onze scriptie zijn de controls in het besturingssysteem. Controls in het besturingssysteem vormen de basis voor de controls die daarboven worden geïmplementeerd. Indien controls op het niveau van een besturingsysteem falen, dan kan dit een negatieve impact


4.1 Controls op besturingssysteemniveau

15

hebben op bovenliggende controles. Hierdoor kan gesteld worden dat controls op een lager niveau effectiever werken dan daar bovenliggende.

4.2 IT General Controls en systeemsetting Om te zorgen dat een organisatie haar doelen behaald richt zij hiervoor onder andere een ‘internal control’ framework in. Internal control is gericht op het waarborgen van integriteit, doelmatigheid en doeltreffendheid van de organisatorische activiteiten [Starreveld 2002]. Onderdeel van dit framework zijn ook de IT-controls. Deze zijn gerelateerd aan de kwaliteitsaspecten beschikbaarheid, integriteit en vertrouwelijkheid (BIV) van data. IT Controls zijn vaak onderverdeeld in de twee categorieën: IT General Controls (hierna ITGC) en IT Application Controls. ITGC bevatten controls met betrekking tot onder andere de IT omgeving, toegang tot programmatuur en gegevens, ontwikkeling van programmatuur en het wijzigen van programmatuur. IT Application controls hebben betrekking op controls gericht op het verwerken van transacties, ook wel ‘input-verwerking-output’ controls genoemd. Om de focus op de scope van ons onderzoek te houden zullen we met name stilstaan bij de ITGC.

4.2.1 IT-beheersprocessen

•

•

•

Logische toegangsbeveiliging dient zeker te stellen dat de juiste personen over de juiste autorisaties beschikken. Belangrijk hierbij is dat rekening gehouden wordt met functiescheiding tussen de gebruikersorganisatie en de IT-beheerorganisatie. Toegang tot systemen en daarmee de mogelijkheid om systeemsettings aan te kunnen passen, zou alleen na een goedgekeurde change door een geautoriseerd persoon uitgevoerd moeten kunnen worden. Changemanagement dient zorg te dragen dat geaccepteerde wijzigingen gecontroleerd uitgevoerd worden. Deze maatregel hangt dus nauw samen met logische toegangsbeveiliging. Als laatst genoemde niet goed werkt, kunnen wijzigingen ongeautoriseerd buiten het gecontroleerde proces van change management om doorgevoerd worden. De afwijkingen die hierdoor ontstaan worden door de standaard IT-beheersingsmaatregelen niet behandeld (ook niet binnen ITIL). Dit leidt in de meeste gevallen tot een omgeving met veel afwijkingen. Back-up & Recovery: belangrijk is dat een goed back-up plan aanwezig is en dat deze ook periodiek op werking getest wordt.

In een situatie waarin de IT-beheersingsmaatregelen, zoals logische toegang- en wijzigingsbeheer adequaat werken, kan men ervan uitgaan dat de systeemsetting op besturingssystemen voldoende betrouwbaar zijn. Immers is middels functiescheiding geborgd dat niet iedereen autorisaties heeft om systeemsettings te kunnen wijzigen. Ook is een wijzigingsprocedure aanwezig die er voor zorgt dat alleen goedgekeurde wijzigingen doorgevoerd worden. In de praktijk blijkt echter dat om allerlei redenen afwijkingen kunnen ontstaan zonder dat deze formeel zijn toegestaan.


IT-beheersmaatregelen zoals logische toegangsbeveiliging, changemanagement en back-up en recovery vallen onder andere binnen de ITGC. Deze moeten er zorg voor dragen dat systemen voldoende betrouwbaar werken en ongeautoriseerde wijzigingen op bijvoorbeeld systeemsetting niet kunnen worden doorgevoerd. In deze paragraaf willen we ingaan op de bovengenoemde ITbeheersingsmaatregelen en de relatie die zij hebben met systeemsettings.

16

Voorbeeld: een webapplicatie welke gecompromitteerd is. De aanvaller zou in theorie dan door misbruik te maken van de lek in de webapplicatie systeemsettings kunnen aanpassen. Afhankelijk van het risico wat een organisatie loopt zouden aanvullende maatregelen getroffen kunnen worden om risico’s te minimaliseren om de betrouwbare werking van de getroffen controls te kunnen waarborgen. Een van de maatregelen die een organisatie kan nemen is het implementeren van een control proces, waarbij geverifieerd wordt of de actuele systeemsettings ingericht zijn conform voorschriften. Dit proces zullen we in de hierna volgende paragraaf toelichten. Dit uiteraard mede naar aanleiding van het feit dat zaken buiten het change management proces om aangepast kunnen worden.

4.3 Control proces Het doel van het control proces is het reduceren van risico’s op systemen met betrekking tot de kwaliteitsaspecten beschikbaarheid, vertrouwelijkheid en integriteit. Het risico dat door middel van het proces afgedekt dient te worden is dat geen ongewenste situatie ontstaat, wat bijvoorbeeld kan leiden tot ongeautoriseerde toegang tot (kritische) systemen. Voor een control proces is het belangrijk dat deze een betrouwbaar en herhaalbaar karakter heeft.

De organisatie of IT-auditor kan er voor kiezen om door middel van een aanvullend control proces, de controle handmatig of geautomatiseerd uit te voeren. Van handmatige controles is bekend dat de kans op het niet detecteren van een onjuistheid groter is dan bij een geautomatiseerde controle. Ook neemt een handmatige controle veel tijd in beslag. Daar de kans op fouten kleiner en de kwantitatieve omvang van een controle groter is bij een geautomatiseerde controle, zijn deze over het algemeen veel effectiever dan handmatige controles. Geautomatiseerde controles kunnen ingesteld zijn in applicaties, databases, besturingssystemen en netwerken. Deze instellingen kunnen op een geautomatiseerde manier worden beoordeeld. Bijvoorbeeld door het op een geautomatiseerde manier analyseren van de systeemconfiguraties ofwel settings waaruit deze configuraties bestaan. Om controleactiviteiten geautomatiseerd in te zetten en deze frequenter uit te voeren zal een proces ingericht moeten worden die dit kan realiseren. Dit proces zal moeten borgen dat besturingssystemen op een juiste en veilige wijze geconfigureerd zijn en dit ook gedurende hun lifecycle blijven. Om het control proces op systeemsettings betrouwbaar te laten verlopen, dienen een aantal stappen uitgevoerd te worden. Het control proces vergelijkt de actuele waarden van een systeemconfiguratie met de waarden die zijn toegestaan. De settings die zijn toegestaan, zouden opgenomen moeten zijn in de SOLL. Hoe men deze settings kan bepalen en een configuratiebaseline kan definiëren hebben


Periodieke vergelijking van de daadwerkelijke inrichting (IST) met de vastgelegde en goedgekeurde instellingen van systeemsettings (SOLL) dient als controlemiddel ingezet te worden om te kunnen vaststellen dat de IST situatie conform SOLL is ingericht en dit ook blijft. Voor afwijkingen die geconstateerd worden kan beoordeeld worden of deze terecht of onterecht zijn. Hiervoor kan een relatie gelegd worden met bijvoorbeeld de IT-beheersingsproces ‘changemanagement’, door te controleren of de afwijkingen door het changeproces geaccordeerd zijn. Bij het uitvoeren van activiteiten voor het controle proces is het daarom belangrijk om een relatie te kunnen leggen met de standaard IT-beheerprocessen binnen een organisatie. Hiermee zouden de afwijkingen op systeemsettings verklaard kunnen worden.

17

we in hoofdstuk 3 uitgebreid behandeld. De actuele waarde ofwel de IST waarde wordt verzameld vanuit de besturingssystemen. Afwijkingen die worden geconstateerd, leiden ofwel tot het herstellen van de setting op de betreffende server, ofwel tot aanpassing van gedefinieerde settings (SOLL). De stappen die binnen het control proces worden uitgevoerd zorgen voor de evaluatie en correctie van de geconstateerde afwijkingen. Toelichting: Het control proces begint met het definiëren van de gewenste situatie. Hiermee ontstaat een basis waarmee in de volgende stap (controle) vergeleken wordt of de huidige situatie conform gewenste situatie is. De resultaten van de (IST – SOLL) vergelijking worden door middel van een rapportage bekend gemaakt aan belanghebbenden bijvoorbeeld management, configuratiebeheerders, etc. In de laatste iteratieve stap (Herstel) worden geconstateerde afwijkingen hersteld door deze systeemsetting terug te brengen naar de gewenste staat of de SOLL aan te passen. Dit kan de input leveren of een trigger zijn voor het changemanagement proces. Het control proces is gebaseerd op de PDCA-cyclus (plan, do, check, act), waardoor gezorgd wordt dat het proces beheerst plaatsvindt en herhaalbaar is.

In hoofdstuk 3 is beschreven hoe systeemsettings ontstaan. Nadat deze settings zijn gedefinieerd zullen deze ook geïmplementeerd worden in systemen om ervoor te zorgen dat deze gedurende de lifecycle op het niveau van techniek compliant zijn ingericht. Om de settings compliant te krijgen en te houden zal gesteund moeten worden op de randvoorwaardelijke IT-beheersprocessen. Deze processen dienen ervoor te zorgen dat de systeemsettings en daarmee natuurlijk ook het systeem zelf op een beheerste wijze uitgerold worden en daarna gedurende hun levensfase niet ongeautoriseerd veranderen. Zoals ook eerder aangegeven bestaat altijd een risico dat kwaadwillende (bijvoorbeeld d.m.v. hacking) ongeautoriseerd systeemsettings kunnen veranderen. De standaard IT-beheerprocessen zoals logische toegangscontrole en changemanagement hebben weinig tot geen aandacht voor wijzigingen die zijn doorgevoerd buiten het proces om. Middels technical compliance van systeemsettings wordt de kans op detectie van een non-compliant configuratie groter. Immers wordt periodiek gecontroleerd of de door de organisatie gedefinieerde configuratiebaseline van kracht is op de systemen. Hierdoor is het mogelijk om wijzigingen in systeemsettings die buiten het proces om zijn doorgevoerd te detecteren en hier vervolgens passende maatregelen voor te treffen.


4.4 Samenvatting en conclusie

18

5 COSO en CobIT In de voorgaande hoofdstukken is beschreven wat onder technische compliance van systeemsettings wordt verstaan en hoe weten regelgeving vertaald kan worden naar systeemsettings. Dit hoofdstuk beschrijft frameworks voor het inrichten en onderhouden van IT-beheersmaatregelen. Deze frameworks geven organisaties handvatten om maatregelen te kunnen treffen om operationele risico’s binnen de IT-processen te beheersen. Het algemeen aanvaarde COSO-model (The Committee of Sponsoring Organizations of the Treadway Commission) voor interne beheersing en o.a. compliance, wordt gezien als de basis voor deze frameworks en om deze reden hebben wij onderzocht of de elementen uit COSO-model voldoende handreiking bieden om de technische compliance te beheersen. We merken wel op dat deze raamwerken geen normen zijn, maar een richtlijn om de beheersing van de IT-beheersmaatregelen te realiseren.

“Understanding internal control and implementing adequate compliance for Sarbanes-Oxley are two overlapping subjects. Two prominent sources for Sarbanes-Oxley guidance are the Committee of Sponsoring Organizations (COSO) and Control Objectives for Information and related Technology (COBIT)”. [ISACA 2005] Daarnaast besteden we aandacht aan CobIT, een framework voor de beheersing van informatietechnologie. Het hoofdstuk wordt afgesloten met een overzicht van de belangrijkste aspecten van deze twee modellen voor de vaststelling van technische compliance. Daarnaast geven we een antwoord op de volgende deelvraag: “Welke aspecten van de bestaande frameworks (COSO, CobIT) kunnen gebruikt worden om de technische compliance van systeemsettings te kunnen beheersen?”

5.1 Wat is COSO? COSO is een management model dat ontwikkeld is door The Committee of Sponsoring Organizations of the Treadway Commission (COSO). Deze commissie heeft naar aanleiding van diverse financiële schandalen een rapport met diverse aanbevelingen en richtlijnen ten aanzien van interne controle en interne beheersing voor het voorkomen van het fraude en financieel wanbeheer uitgebracht. Dit rapport biedt een harmonisatie en uniformering voor de inrichting en/of verbetering van het interne F IGUUR 5: COSO MODEL controlesysteem. Snel ontstond echter de vraag hoe de aanbevelingen van de commissie moesten/konden worden verwezenlijkt. In 2004 is het model geactualiseerd. Het geactualiseerde model richt zich, naast interne controle, onder andere op het risicomanagement. Behoefte voor het


In ons vakgebied staan deze twee frameworks bekend als dé frameworks voor de beheersing van de interne controle en o.a. compliance, zoals het stukje uit een artikel van ISACA Journal hierboven beschrijft. Wij hebben onderzocht hoe en of COSO en CobIT gebruikt kunnen worden voor de technical compliance van de systeemsettings.

19

identificeren, waarderen en managen van de risico’s is een van de belangrijkste aanleidingen geweest voor de actualisatie van dit model. Het geactualiseerde model staat bekend als COSO II of Enterprise Risk Management Framework (ERM). COSO behoort tot één van de standaard referentiemodellen die door IT-auditors worden gebruikt. Dit geactualiseerde model richt zich niet alleen maar op de interne controle, maar op het gehele interne beheersingssysteem en onder andere de IT-gerelateerde risk management. COSO onderscheidt vier categorieën of resultaatgebieden voor Enterprise Risk Management (zie ‘Figuur 5: coso model’). Deze zijn: • •

• •

Strategisch: hierbij gaat het om high-level doelen die met de missie van de onderneming samenhangen en die ondersteunen. Operationeel: dit betreft de effectiviteit en efficiency van de inzet van middelen en de mate waarin doelstellingen bereikt worden. Hieronder valt de IT. In het geval van technical compliance kunnen we ons richten tot de effectiviteit en efficiency van de inzet van middelen (processen en procedures) waarmee de doelstellingen m.b.t. compliant zijn behaald kunnen worden. Rapportage: dit betreft de betrouwbaarheid van de rapportages zodat met redelijke zekerheid de feitelijke stand van zaken weergegeven wordt. Compliance: hierbij gaat het om het voldoen aan weten regelgeving.

• •

•

• • •

• •

Internal Environment: dit is de basis voor de andere componenten en omvat in feite de bedrijfscontext waarbinnen internal controle (beheersen van de risico’s) plaatsvindt. Objective Setting: uitgaande van de nadruk op risicomanagement is het stellen van (strategische) doelen van belang, want anders blijft onduidelijk welke gebeurtenissen risico’s inhouden voor het realiseren van de doelen. Event Identification: dit betreft het identificeren van interne en externe gebeurtenissen die de realisatie van doelstellingen beïnvloeden. Daarbij wordt onderscheid gemaakt tussen de risico’s en kansen. De kansen worden teruggekoppeld naar het proces van het stellen van doelen. Risk Assessment: hierbij gaat het om het identificeren, beoordelen en beheersen van risico’s in het licht van de doelstellingen voor de vier resultaatgebieden. Risk Response: na het identificeren en beoordelen van risico’s moet de van belang zijnde reactie worden vastgesteld, mede in het kader van het risiconiveau dat aanvaardbaar wordt geacht. Control Activities: binnen de COSO-optiek gaat het hierbij vooral om ‘policies en procedures’ waarmee internal control geëffectueerd wordt. Gezien de achtergrond van de deelnemers (auditors) van de ontwikkeling van COSO weerspiegelen de policies en procedures het auditingperspectief. Informatie en Communicatie: dit betreft een breed gebied van financiële en niet-financiële informatie, kwaliteit daarvan en de systemen die de informatie voortbrengen. Monitoring: deze laatste categorie betreft het proces dat periodiek onderzoekt of het systeem van internal control effectief werkt. Monitoring wordt binnen het COSO model beschreven als middel dat als doel heeft om ervoor te zorgen dat de werking van de controls continu effectief is.


Enterprise Risk Management van COSO bestaat uit acht samenhangende componenten. Deze componenten zijn afgeleid van de wijze waarop het management de organisatie en de onderliggende processen zou kunnen leiden.

20

F IGUUR 6: COSO ENTERPRISE RISK MANAGEMENT MODEL

In de voorgaande hoofdstukken hebben we vastgesteld dat compliance, heel ‘letterlijk’ gezegd, het voldoen aan weten regelgeving betekent. Hierdoor komen het ontwerp, de werking en het onderhoud van IT-systemen en netwerken binnen het aandachtsgebied van compliance. Om het gewenste niveau van compliance te kunnen beheersen zijn activiteiten binnen de IT-operatie, waaronder wijzigingsbeheer, incidenten- en probleembeheer en zogenaamde releasemanagement van IT-systemen van groot belang. De activiteiten die plaatsvinden onder de hiervoor genoemde processen mogen geen negatieve invloed hebben op de beschikbaarheid, integriteit en vertrouwelijkheid van gegevens. Hierbij is het ontwerp van IT-systemen (in ons geval serverplatformen) belangrijk. Het gaat dan om de processen en hun beveiligingsaspecten. Binnen de activiteiten voor bijvoorbeeld het ontwerpen van veilige netwerktoegang en het beheer van autorisaties, zijn van belang gebruikers, klanten, businesspartners en leveranciers. In het ontwerp zal dus rekening gehouden moeten worden met de wijze waarop dit wordt geïmplementeerd en dat bijvoorbeeld de verschillende belanghebbende partijen alleen toegang hebben tot hun eigen data. Juiste parametrisering van systeemsettings is hierbij dus van groot belang. Dit illustreert dat compliance vaak impliciet met het gehele ontwerp van de serverplatformen verbonden is. De vraag die nu aan de orde komt is of het COSO model toereikend is om de (technische) compliance van de systeemsettings te kunnen beheersen, zoals deze hierboven beschreven is. De bevindingen van het onderzoek naar het COSO model vertellen ons dat binnen het perspectief van COSO het identificeren, beoordelen en beheersen van risico’s met het oog op de doelstellingen voor de vier resultaatgebieden, waaronder compliance valt, een flinke dosis aandacht krijgt. Met betrekking tot de technisch compliance van systeemsettings denken we hierbij aan de risico’s als gevolg van ongeautoriseerde toegang tot IT-systemen (event identification). Dit zijn de risico’s die de juiste inrichting van een besturingssysteem en betrouwbare werking van programmatuur in gevaar kunnen brengen. Daarnaast wordt de integriteit van de data die op het systeem aanwezig is in gevaar


5.1.1 Bruikbaarheid van COSO voor de beheersing van de technische compliance

21

gebracht. Maatregelen op het terrein van gegevensbeveiliging en toegang tot de systeemsettings zijn dan mogelijke antwoorden op het geïdentificeerde risico’s (risk response). Het identificeren en beheersen van de risico’s die de technische compliance van de systeemsettings in gevaar brengen is dan uiteraard van belang. De logica en de achterliggende gedachte van COSO stelt dat een krachtig systeem voor interne beheersing essentieel is voor het beheersen van de risico’s. Als dit vertaald wordt naar, wat wij onder technische compliance verstaan, het inrichten van een besturingssysteem middels een samenstel van parametrisering, technisch, functioneel en operationeel beheer zodat voldaan wordt aan weten regelgeving, kunnen we vaststellen dat de componenten event identification en risk response uit het COSO model gebruikt kunnen worden om het risicomanagement op te kunnen zetten. Naast een risk management dat opgebouwd wordt door middel van het COSO model, lijkt dat in het COSO-raamwerk de focus voor de beheersing van de risico’s ligt op ‘control activities’ die neergelegd zijn in de policies en procedures. Op zich niet verkeerd, want we hebben procedures en policies hard nodig om de systeemsettings onder controle te houden. Echter, het COSO model gaat uit van een visie, waarbij een proces risico’s kan identificeren, beoordelen en beheersen. Het model zou het management een handreiking moeten bieden hoe om te gaan met onzekerheden. Gezien de moeilijkheidsgraad en complexiteit van compliance en de technologie lijkt dit standpunt discutabel. Inderdaad met COSO kunnen we risk management opzetten, maar hoe bepalen we de scheiding tussen de systemen? Hoe kunnen we de mate van encryptie bepalen? Dit zijn allemaal vragen die we moeilijk of niet beantwoord zullen krijgen met COSO. Veel organisaties worstelen juist met de vraag hoe en waar te beginnen. COSO vertelt op een hoog niveau alleen wat er gedaan kan worden en dus niet hoe, ofwel het gaat niet in op de details. COSO is dus bruikbaar voor opzet, maar niet voor detaillering en 'bestaan en werking'.

Control Objectives for Information and related Technology beter bekend als CobIT is het model dat gericht is op de (interne) beheersing van informatietechnologie (IT) en opgesteld door het IT Governance Institute. Het uitgangspunt van het CobIT model is dat een intern systeem voor beheersing en risicomanagement essentieel is voor de succesvolle ondersteuning van de business door IT. De kern van het model zijn de vier fasen zoals in onderstaand figuur weergegeven.


5.2 Wat is CobIT?

22

F IGUUR 7: COBIT MODEL

Het CobIT model en de makers ervan claimen dat het framework zeker stelt dat business en ITalignment ontstaat, de bijdragen van IT hun maximum behalen, de IT-middelen verantwoord worden ingezet en de risico’s in de IT adequaat beheerst worden. Met de zojuist benoemde bewering, zouden we kunnen vaststellen dat het CobIT model in ieder geval als een richtlijn voor de beheersing van de technical compliance van de systeemsettings gebruikt zou kunnen worden. In de opvolgende paragrafen geven wij aan of dit inderdaad zo is.

5.2.1 Bruikbaarheid van CobIT voor de beheersing van de technische compliance Het CobIT framework is voor het gestructureerd inrichten van een IT-organisatie en de beheersing van de risico’s in IT. CobIT stelt organisaties in staat om op basis van algemeen geaccepteerde Best Practices de IT-beheersmaatregelen in te richten. De kern van het model wordt gevormd door de vier fasen zoals weergegeven in figuur 6. CobIT heeft 34 IT-processen verdeeld over vier (IT)domeinen: Plan and Organize, Acquire and Implement, Deliver and Support en Monitor and Evaluate. Per ITproces zijn op een hoog niveau ‘control objectives’ gedefinieerd. Door het implementeren van deze


‘Plan and Organize’ vormt het startpunt voor de vier fasen en het eindpunt is ‘Monitor & Evaluate’. Monitor & Evaluate levert de input om de cyclus, of delen daarvan, opnieuw te doorlopen. In alle fasen zijn, op een hoog niveau, taken benoemd. Deze taken worden aangeduid als ‘processen’.

23

Ook binnen het CobIT model hebben de benoemde ‘gedetailleerde’ beheersdoelstellingen een algemeen karakter en de feitelijke realisatie van die beheersdoelstellingen maakt het nodig organisatorische competenties en processen te definiëren. Terugdenkend aan onze definitie van de technical compliance van de systeemsettings zouden we kunnen aannemen dat we met CobIT competenties voor de IT-organisatie en specialisten voor de beheersing van de technical compliance kunnen definiëren. Die competenties komen in het model echter niet aan de orde. Omdat de inrichting van IT-organisatie op een high-level gedefinieerd wordt is het CobIT model eerder een checklist van de mogelijke aandachtsgebieden voor de inrichting van IT. Verder is het onderscheid tussen strategieontwikkeling, de implementatie van strategie en de operatie van IT, die wij bijvoorbeeld zouden kunnen gebruiken bij het bepalen van systeemsettings, niet duidelijk beschreven. Bij de eerste fase komen we al de aspecten die te maken hebben met implementatie- (manage projects) en operatietaken (manage IT human resources) tegen. Bij de volgende fase komen we high-level taken tegen die bij strategieontwikkeling horen (Identify automated solutions). Een voorbeeld: het is niet duidelijk hoe we IT-oplossingen zouden kunnen identificeren (tweede fase) en hoe we de beveiliging van de IT-systemen zouden kunnen zekerstellen (derde fase). In feite leidt dit tot onvoldoende onderscheid tussen de design van de IT-infrastructuur en de operatie daarvan.


control objectives wordt getracht de gewenste resultaten of doelstellingen die een organisatie heeft vastgesteld, te behalen. CobIT heeft richtlijnen opgesteld om deze IT-processen te kunnen controleren en te meten. Deze richtlijnen bevatten volwassenheidsmodellen, kritieke succesfactoren, Key Goal Indicatoren en Key Performance Indicatoren voor elk proces. Het volwassenheidsmodel binnen CobIT is een manier om de huidige en gewenste positie van de IT-organisatie te bepalen en te vergelijken met de ‘best practices’. Daarnaast bevat het CobIT de richtlijnen voor de audit. Deze richtlijnen bieden niet alleen de auditor, maar ook de organisatie uitgangspunten om een audit uit te kunnen voeren. Naast de bovengenoemde richtlijnen bevat CobIT diverse aansluitingen op onder andere best practices zoals ITIL, Prince 2, Code voor Informatiebeveiliging, SOx, enz. Uitgangspunt is dat CobIT een goed vertrekpunt is om ook gebruikt te kunnen worden om de aanvullende beheersmaatregelen voor de inrichting van het besturingssysteem voor de technische compliance van systeemsettings te kunnen bepalen, te implementeren en te beoordelen. De top-down en planmatige benadering voor de beheersing van IT en risicomanagement is kenmerkend voor het CobIT model. Echter, de focus op de beheersing van IT en risicomanagement maakt het CobIT model erg bureaucratisch met een groot aantal beheersdoelstellingen (liefst 214). De toepassing van het CobIT model lijkt daarom meer te gaan om de vorm dan om de inhoud van de ITbeheersmaatregelen. De benadering van CobIT is vergelijkbaar met de ISO-9000 richtlijnen voor de kwaliteitsverbetering. Ook voor deze richtlijnen geldt de procedurele methodiek gericht op het volgen van de vastgestelde taken (procedures) in de veronderstelling dat de kwaliteit van de ITinrichting met daarbij behorende IT-beheersmaatregelen verbeterd wordt. Voor de beheersing van de technical compliance van de systeemsetting met behulp van het CobIT model blijkt dit volgens ons niet waar te zijn. In het CobIT model zijn vier opeenvolgende fasen met daarin 34 (high-level) taken oftewel ‘processen’ aangeduid. Één proces wordt gezien als een verzameling van de activiteiten die de voorgedefinieerde input transformeren naar de gewenste output. Als we dit vertalen naar de activiteiten binnen de technical compliance kunnen we denken aan het ontstaan van de policies, standaarden en procedures (zie hoofdstuk 3).

24

Het ontwerpen, eigenlijk het vertalen van het strategische beleid naar operationele maatregelen, is benadrukt in hoofdstuk 3. De benadering die CobIT voorschrijft, besteedt niet of nauwelijks aandacht voor het ontwerpen van IT-systemen en de competenties die daarbij van belang zijn. Denk hierbij aan configuratie van settings die nodig is voor de inrichting van besturingssystemen. Wet- en regelgeving bevat nagenoeg geen specifieke eisen die van toepassing zijn op de inrichting van een serverplatform en de configuratie daarvan. De regelgeving stelt wel met name eisen aan de organisatie om de operationele risico’s in te perken. Het inperken van operationele risico’s dient dan ook bij de IT-(beheer)organisatie plaats te vinden door het nemen van adequate beheersmaatregelen. Deze maatregelen dienen getroffen te worden voor de IT-processen waarin operationele risico’s worden gelopen die de technische compliance in gevaar brengen. Hieronder hebben we een high-level activiteit van CobIT opgenomen om aan te tonen dat deze control niet geschikt is om systeemsettings te kunnen definiëren en controleren in het kader van technical compliance.

D5 Ensure System Security De titel van activiteit D5 van CobIT doet ons vermoeden dat het bruikbaar is binnen technical compliance. Hieronder hebben we een omschrijving van CobIT activiteit D5 Ensure System Security opgenomen:

Deze beschrijving geeft aan dat deze activiteit van CobIT bruikbaar is om de technical compliance van systeemsettings te kunnen beheersen. Echter als we verder naar de inhoud van de activiteit kijken dan komen we het volgende tegen:

DS5.1 Management of IT Security “Manage IT security at the highest appropriate organisational level, so the management of security actions is in line with business requirements.”

DS5.2 IT Security Plan “Translate business information requirements, IT configuration, information risk action plans and information security culture into an overall IT security plan. The plan is implemented in security policies and procedures together with appropriate investments in services, personnel, software and hardware. Security policies and procedures are communicated to stakeholders and users.”


“The need to maintain the integrity of information and protect IT assets requires a security management process. This process includes establishing and maintaining IT security roles and responsibilties, policies, standards and procedures. Security management also includes performing security monitoring and periodic testing and implementing corrective actions for identified security weaknesses or incidents. Effective security management protects all IT assets to minimise the business impact of security vulnerabilities and incidents.”

25

Wat opvalt aan de activiteit is dat zij voornamelijk de ‘wat’ beschrijft, namelijk dat er een IT Security plan aanwezig dient te zijn en dat deze in overeenstemming is met bedrijfsdoelen. Maar de belangrijkste vraag is: hoe wordt dit bereikt? Organisaties worstelen namelijk nog steeds met de vraag ‘hoe?’. Als we het bijvoorbeeld hebben over het versleutelen van gevoelige data dan weten organisaties over het algemeen dat dit volgens weten regelgeving geïmplementeerd moet worden. Echter welke data (classificatie) en hoe versleuteld dient te worden is veelal onbekend. Ook is het belangrijk dat bekend is volgens welke standaarden en procedures versleuteling plaats dient te vinden. Het CobIT framework geeft simpel gezegd aan “gij zult uw systeem beveiligen” en stopt hier vervolgens. Om technical compliance op het niveau van systeemsettings (operationeel niveau) te beheersen is de inzet van CobIT niet doeltreffend.

5.3

Samenvatting en conclusie

COSO en CobIT zijn twee frameworks voor de inrichting van interne beheersing van ITbeheersmaatregelen. Binnen het COSO perspectief is het identificeren, beoordelen en beheersen van risico’s van groot belang. Het CobIT framework wordt gebruikt voor het gestructureerd inrichten van een IT-organisatie en de beheersing van de risico’s hierin. Deze frameworks hebben wij bestudeerd. Daarbij hebben wij proberen vast te stellen welke elementen binnen deze frameworks gebruikt kunnen worden om de technische compliance van systeemsettings op een serverplatform te beheersen. De conclusie is dat beide frameworks niet beschreven zijn om op operationeel niveau te gebruiken. Noch COSO noch CobIT bieden voldoende handreiking om op operationeel niveau de benodigde processen voor technische compliance te beheersen. In dit hoofdstuk hebben we getracht antwoord te geven op deelvraag:

Hierop is geen direct antwoord mogelijk. Voor het risk management behandelt het COSO model elementen risk identification en risk response. Het CobIT model biedt op een abstract niveau aan wat op het gebied van systeembeveiliging gedaan moet worden. Dit biedt een mogelijke handreiking voor het inrichten van een controleproces, maar hoe hier vorm aangegeven kan worden ontbreekt.


“Welke aspecten van de bestaande frameworks (COSO, CobIT) kunnen gebruikt worden om de technische compliance van de systeemsettings te kunnen beheersen?”

26

6 Analyse interview resultaten Toetsing van het theoretische kader hebben we gedaan door een aantal interviews af te nemen. De functionarissen die wij hiervoor hebben geïnterviewd hebben de functies van (technical)auditors, security specialisten en riskmanagers. Middels de interviews is getracht antwoord te krijgen op onderstaande twee vragen. • •

Welke aspecten van de bestaande frameworks (COSO, CobIT) kunnen gebruikt worden om de technische compliance van de systeemsettings te kunnen beheersen? Wat voor toegevoegde waarde kan de technische compliance van de systeemsettings aan de ITauditor leveren?

Welke aspecten van de bestaande frameworks (COSO, CobIT) kunnen gebruikt worden om de technische compliance van de systeemsettings te kunnen beheersen? Onze verwachting was dat de geïnterviewden de onderdelen risk management en compliance van COSO zouden noemen. Met betrekking tot CobIT was onze verwachting dat de geïnterviewden dit model niet toepasbaar zouden vinden op het niveau van systeemsettings

Wat voor toegevoegde waarde kan de technische compliance van systeemsettings leveren aan de IT-auditor? Onze verwachting was dat de geïnterviewden een antwoord zouden geven in de trant van effectieve en efficiënte inrichting van een controle framework waarmee de compliance van systeemsettings aantoonbaar gemaakt kan worden.

Niet alle geïnterviewden konden deze vraag beantwoorden, omdat de term technical compliance niet bekend was. Daarnaast hebben de meeste organisaties geen controle framework ingericht voor de beheersing van technical compliance. Geïnterviewden die enigszins bekend waren met het onderwerp hebben aangegeven dat de toegevoegde waarde voornamelijk zit in de integrale controle framework. waarmee serverplatformen worden gecontroleerd tegen vastgestelde beveiligingsconfiguraties.


Niet alle geïnterviewden konden deze vraag beantwoord omdat ze niet bekend waren met de aspecten van COSO en CobIT. De geïnterviewden die wel bekend waren met COSO hebben aangegeven dat de aspecten zoals risk assessment en response mogelijkheden bieden voor het opzetten van het risk management. Daarnaast is het onderdeel event identification genoemd als het onderwerp waarmee detectie van de ‘security breaches’ ingericht kan worden. Daarnaast was het algemeen beeld dat COSO op een strategisch niveau aangeeft wat er gedaan kan worden, maar niet hoe. De geïnterviewden gaven ook voor CobIT aan dat dit bruikbaar was op strategisch niveau, maar dan meer specifiek voor IT.

27

7 Conclusie Op basis van voorgaande hoofdstukken kan worden aangegeven dat technical compliance een complex onderwerp is. De complexiteit begint al bij de definitie van compliance. Uit onderzoek blijkt dat verschillende interpretaties mogelijk zijn. Het onderwerp: technical compliance van systeemsettings, is vrij onbekend. In de literatuur is hier dan ook weinig over te vinden. Kiezen van definitie voor ons onderzoek was daarom dan ook een uitdaging. Voor dit onderzoek hebben wij de volgende definitie gedefinieerd: Technische Compliance van systeemsettings is het inrichten van een besturingssysteem middels een samenstel van parametrisering, technisch beheer en operationeel beheer zodat voldaan wordt aan weten regelgeving, en waarmee gezorgd wordt voor een betrouwbare werking van het informatiesysteem zodat de door de organisatie geformuleerde bedrijfsdoelstellingen worden ondersteund. Uit bovenstaande definitie lezen we dat voor de technical compliance van systeemsettings in het kader van ons onderzoek een aantal aspecten van belang zijn. Dit zijn onder andere een besturingssysteem, parametrisering, technisch- en operationeel beheer, weten regelgeving, betrouwbare werking. Uit onderzoek blijkt dat het samenspel tussen deze aspecten ontbreekt, waardoor er deficiënties ontstaan in de uitvoering van het beveiligingsbeleid. Een geïntegreerd framework die al deze aspecten met elkaar verbindt is dus een must.

Voor dit onderzoek is de doelstelling geweest om een antwoord te geven op de volgende vraag: Op welke wijze kan de technische compliance van systeemsettings op een serverplatform de mate van de efficiëntie en effectiviteit van audits verhogen? De technical compliance van systeemsettings kan zorg dragen dat het ontstaan en de naleving van de policies, standaarden en procedures hogere mate van de efficiëntie en effectiviteit krijgen. Technical compliance werkt zowel preventief als detectief en de kracht van de technical compliance ligt daarin dat de drie veel voorkomende lagen binnen de organisaties (strategisch, tactisch en operationeel) dichter bij elkaar komen. Dit wordt voornamelijk bereikt door de top-down benadering (hoofdstuk 3). Technical compliance dwingt de organisaties een framework voor de beheersing van compliance in te richten waarin ‘best practices’, configuratiestandaarden (denk aan NIST) en procedures ingericht worden, waarmee vanaf het hoogste niveau in de organisatie het operationeel niveau op een laag detail niveau opgezet wordt. De kracht van technical compliance zit in de volgende punten:


In weten regelgeving is over het algemeen niet concreet opgenomen waar techniek aan dient te voldoen. Wat wel in weten regelgeving teruggevonden kan worden is dat voorwaarden voor de goede beheersing worden gesteld. Dit kan bijvoorbeeld zijn het treffen van adequate maatregelen om de privacy van klantgegevens te beveiligen. Bij de vertaling van weten regelgeving is het verstandig om vast te stellen aan welke kwaliteitseisen voldaan moet worden. Hierbij kan gedacht worden aan beschikbaarheid, integriteit en vertrouwelijkheid. Een bank zal bijvoorbeeld aan diensten op het gebied van internetbankieren hogere eisen stellen wat betreft deze kwaliteitsaspecten. Als deze eisen vertaald worden naar technische maatregelen, bijvoorbeeld implementeren van logging, zullen uiteindelijk systeemsettings een belangrijke rol spelen.

28

•

•

Topdown model waarmee controls in het besturingssysteem ontstaan die voldoen aan wet- regelgeving. Dit wordt bereikt door een samenspel van de verschillende lagen in een organisatie waarin policies, standaarden en procedures ontstaan waarmee de vertaalslag van weten regelgeving naar systeemsettings aantoonbaar wordt gemaakt. Het controleproces waarmee gecontroleerd wordt of de door de organisatie bepaalde configuratiebaseline effectief is op het serverplatform. Als de IT-auditor de opzet en bestaan van de inrichting van technical compliance van systeemsettings met voldoende mate van zekerheid heeft beoordeeld, kan de IT-auditor de effectieve werking van controls in het besturingssysteem beoordelen aan de hand van de resultaten van het control proces en dit ook aantoonbaar maken. Wat we hiermee kunnen bereiken is dat er voldoende bouwstenen ontstaan voor een effectieve en efficiënte audit, omdat technical compliance bewijsmateriaal van de effectieve werking van de systeemsettings levert.

7.1 Aandachtsgebieden IT-auditor

Door de grote afhankelijkheid van de IT en de complexiteit van compliance is de IT-auditor de aangewezen persoon om een oordeel te geven over de opzet, bestaan en werking van de technische compliance van de systeemsettings. Naast de standaard controle van de IT-beheersmaatregelen (IT General Controls) zal de IT-auditor tijdens de controle van de technical compliance moeten vaststellen of: • • •

De vertaling van de weten regelgeving volgens het top-down model heeft plaats gevonden; De juiste best practices gebruikt zijn; De opzet voldoende onderbouwd is met de policies, standaarden en procedures.

Bij het wijzigen of intreding van nieuwe weten regelgeving zal de IT-auditor moeten vaststellen dat de juiste vertaling plaats heeft gevonden en via een formele procedure.


Tijdens het uitvoeren van ons onderzoek zijn we goed bekend geraakt met de problematiek die de term compliance met zich meebrengt. Compliance wordt op meerdere manieren geïnterpreteerd, maar waar het op neer komt is het voldoen aan weten regelgeving (zowel extern als intern). De impact van deze regels op IT lijkt zich vooral te concentreren op de beschikbaarheid, integriteit en vertrouwelijkheid van de IT-voorzieningen. Veel van de weten regelgeving geeft echter geen concrete eisen aan de IT. Daarom is de vertaling van deze wetten naar de concrete maatregelen, in ons geval systeemsettings, erg lastig. Organisaties worstelen met de vraag hoe en de bestaande frameworks die voorgesteld worden als de frameworks voor de inrichting van de beheersing van compliance geven vaak antwoord op de vraag wat. Vanuit het onderzoek dat wij uitgevoerd hebben kunnen een aantal punten opgesomd worden als aandachtsgebieden voor de IT-auditor bij de aanraking van de technical compliance van de systeemsettings.

29

BIJLAGE I: LITERATUURLIJST Boeken Estublier, J. (1999). System Configuration Managemen Gemeente Amsterdam (1994). Handboek Informatiebeveiliging Halpern, M. (2007). The language of compliance Bladergroen, J. (2002). Planning en beheersing van IT-dienstverlening Koppens, S. (2002). Operationeel beheer van informatiesystemen Praat, J. & Suerink, H. (2004). Inleiding EDP-auditing Starreveld, van Leeuwen en van Nimwegen (2002). Bestuurlijke informatieverzorging. Cambray, D. (2006). IT Security Management, itSMF Hoogervorst, J. (2007). Enterprise governanace & architectuur Root, J. Steven (1998). Beyond COSO

Artikelen, Rapporten Ross, S. J. (2007). Automating Complinace. Sethuraman, & Vijayakumar. (2006). Enhancing Security Compliance. ISSA. Voon, P. (june 2009). MOF to COBIT/VAL IT Comparison and cross-implementation guide. Microsoft Cheney, S. R. (2009). Aspecten die u moet kennenn over i5/OS security compliance. Power Business Magazine. Beckers, P. (2003). Complinace en internal audit. Colak, A. & Haq, H. (2009). Effectiviteit van GRC tools. Vrije Universiteit Amsterdam. Ezzine, & Achrouch. (2010). Business and IT alginment. Goosens. (2008). Pragmatisch starten met informatiebeveiliging in een divisiestructuur. Ibrahim, F. & Hallemeesch, D. (2008, Maart). Het effect van GRC-software op de jaarrekening controle. Roon, V. & Schajik, V. (2009). ICT Complinacy. Vries, D. (2009). CAATs. Le Comte, M. (2007). IT Audit en Sarbanes-Oxley. Vrije Universiteit Amsterdam. Paans, R. (2007, September 17). IT-beheer en IT-audit (college - Vrije Universiteit Amsterdam). Rutkens, E. (2004). Risicoanalyse gemakkelijk gemaakt. Compact. Leenslag, W. (2007). IT-governancebenaderingen: ..beyond complinace. Compact 2007/1. Koops, B,J. & Bautz, (1995). De waarde van encryptie in het gemeenschappelijk verkeer. IT Governance Institute, (2007). COBIT 4th Edition IT Assurance Guide 4[1].1 IT Governance Institute, (2007). COBIT 4th Edition IT Governance Implementation Guide 4[1].1 Liefers, R. Daniel, v. B. (2006). Compliance en IT-beheer Kazil, P. (2006). College materiaal IT Audit opleiding VU ISACA (2005) Journals volume 2 ISACA (2009) Journals volume 1

Internet Kazil, P. (n.d.). EDP Audit Pool (Rijks Audit Dienst). Retrieved from www.rad.nl. CodeIdol.com (2009). Written Security Policies www.isaca.org (Information Systems Audit and Control Association) www.pivb.nl (Platform voor informatie beveiliging)


Meynen, P. R. How to Write a Security Policy. ISACA.

30

BIJLAGE II: FIGURENLIJST


Figuur 1: opbouw scriptie........................................................................................................................ 4 Figuur 2: ontstaan settings .................................................................................................................... 10 Figuur 3: ontstaan van settings(2) ......................................................................................................... 14 Figuur 4: sterkte van controls ............................................................................................................... 15 Figuur 5: coso model ............................................................................................................................. 19 Figuur 6: coso enterprise risk management model .............................................................................. 21 Figuur 7: cobit model ............................................................................................................................ 23

31

Technical Compliance van systeemsettings

Recommend Documents