Technical Compliance van systeemsettings

Transcriptie

1 Technical Compliance van systeemsettings Controlling the systemconfiguration VRIJE UNIVERSITEIT VAN AMSTERDAM 1 oktober 2010 Opgesteld door: Mustan Kurt, Mili Hadziomerovic

2 Technical Compliance van systeemsettings Controlling the systemconfiguration Titelblad Studenten Naam : ing. M (Mustan) Kurt ing. M (Mili) Hadziomerovic Studentnummer : Teamnummer : Telefoonnummer : Mustan.kurt@gmail.com nered187@yahoo.com Organisatie : Wolfit - IT Security Professionals Duijnborgh Audit b.v. Begeleiders Begeleider VU Bedrijfscoach : dhr. Kees Van Hoof : 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

3 INHOUDSOPGAVE 1 INLEIDING AANLEIDING SAMENHANG ONDERZOEK EN HET VAKGEBIED IT AUDITING PROBLEEMSTELLING DOELSTELLING VAN HET ONDERZOEK DE SCOPE VAN HET ONDERZOEK DE METHODE VAN HET ONDERZOEK OPBOUW VAN HET ONDERZOEK THEORETISCH KADER: TECHNISCHE COMPLIANCE VAN SYSTEEMSETTINGS BEGRIP COMPLIANCE BEGRIP SYSTEEMSETTING TOTSTANDKOMING VAN SYSTEEMSETTINGS TOP-DOWN MODEL POLICY, STANDAARDEN EN PROCEDURES POLICY STANDARDS PROCEDURES SAMENVATTING EN CONCLUSIE RANDVOORWAARDEN TECHNISCHE COMPLIANCE CONTROLS OP BESTURINGSSYSTEEMNIVEAU IT GENERAL CONTROLS EN SYSTEEMSETTING IT-BEHEERSPROCESSEN CONTROL PROCES SAMENVATTING EN CONCLUSIE COSO EN COBIT WAT IS COSO? BRUIKBAARHEID VAN COSO VOOR DE BEHEERSING VAN DE TECHNISCHE COMPLIANCE WAT IS COBIT? BRUIKBAARHEID VAN COBIT VOOR DE BEHEERSING VAN DE TECHNISCHE COMPLIANCE SAMENVATTING EN CONCLUSIE ANALYSE INTERVIEW RESULTATEN CONCLUSIE AANDACHTSGEBIEDEN IT-AUDITOR BIJLAGE I: LITERATUURLIJST.. 30 BIJLAGE II: FIGURENLIJST. 31

4

5 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 wet- en 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 wet- en 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? 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. 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 1

6 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 Enron 1 affaire en daarop volgende boekhoudschandalen veel organisaties te maken hebben gekregen met extra wet- en regelgeving die van toepassing is op hun IT-omgeving, zoals bijvoorbeeld SOx. Gebruikte technieken om te voldoen aan deze wet- en 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 wet- en 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 wet- en regelgeving en de interne regels. De modellen en methodieken die door organisaties worden gebruikt zijn echter zeer divers. 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 wet- en regelgeving en tevens de interne beleidsregels). Wat daarbij opvalt is dat, terwijl het op zichzelf al een enorme opgave is om te voldoen aan wet- en 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. 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 wet- en regelgeving (interne en externe). 1 Bedrijf dat ten onder ging aan een boekhoudschandaal [ 2

7 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 COSO 2 en CobIT 3 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 wet- en 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? Om een antwoord te kunnen geven op de centrale onderzoeksvraag zijn voor dit onderzoek viertal deelvragen geformuleerd: Wat wordt verstaan onder de technische compliance van systeemsettings op een serverplatform? Hoe kan wet- en 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?

8 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 wet- en 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 Onderstaand figuur geeft weer hoe het onderzoek opgebouwd is. FIGUUR 1: OPBOUW SCRIPTIE 4

9 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 wet- en 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 wet- en 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

10 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 wet- en regelgeving en richtlijnen van de organisatie zelf. 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. 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/os 4 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 wet- en regelgeving. 4 I5/OS is een besturingssysteem gebruikt op een IBM Power system 6

11 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.... Paans geeft een nog iets andere uitleg aan het begrip door een directe relatie te leggen naar de interne controle. 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. 7

12 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 wet- en regelgeving, en waarmee gezorgd wordt voor een betrouwbare werking van het technisch systeem zodat de door de organisatie geformuleerde bedrijfsdoelstellingen worden ondersteund. 8

13 3 Totstandkoming van systeemsettings In dit hoofdstuk trachten wij antwoord te geven op de vraag hoe wet- en 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 informatiebeveiliging 5. 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 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. 3.1 Top-down model 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. 5 officieel de ISO-IEC

14 FIGUUR 2: ONTSTAAN SETTINGS [SETHURAMAN 2006] 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 10

15 vastgelegde acties met behulp van procedure beschrijvingen, die exact weergeven hoe de inrichting moet plaatsvinden 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. 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 wet- en 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. 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 techniek- en 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 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 11

16 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. 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. 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] 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 12

17 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

18 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. FIGUUR 3: ONTSTAAN VAN SETTINGS(2)[CODEIDOL.COM 2009] In dit hoofdstuk hebben we antwoord proberen te geven op de deelvraag: Hoe kan wet- en regelgeving vertaald worden naar systeemsettings? Uit onderzoek blijkt dat men uit wet- en 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. 14

19 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. 4.1 Controls op besturingssysteemniveau FIGUUR 4: STERKTE VAN CONTROLS [PAANS 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 15

20 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 IT-beheersprocessen 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. 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. 16