Betrouwbare applicaties realiseren

Transcriptie

1 Betrouwbare applicaties realiseren Een stelsel van maatregelen voor applicatieontwikkeling Scriptie ter afronding van de post-graduate opleiding IT-audit aan de Vrije Universiteit te Amsterdam R. Veenendaal Ing. A.F. Goudbeek Apeldoorn, 15 juni 2011 Vrije Universiteit Amsterdam Faculteit der Economische Wetenschappen en Bedrijfskunde Versie :

2 VOORWOORD In het kader van de afronding van onze studie IT-audit aan de Vrije Universiteit Amsterdam hebben wij een onderzoek gedaan op het gebied van applicatieontwikkeling en uitgewerkt in deze scriptie. Wij zijn beide werkzaam bij de Belastingdienst, onderdeel van het ministerie van Financiën. Rene Veenendaal werkt als EDP-audit medewerker bij kantoor Almere, en is in zijn functie betrokken bij het ondersteunen van financiële audits, door middel van IT audits en audit automation. Arnoud Goudbeek is als Beveiligingsadviseur werkzaam binnen het Centrum voor Applicatieontwikkeling en Onderhoud (B/CAO), de aanbodzijde. In zijn functie is hij betrokken bij het realiseren van business applicaties voor de Belastingdienst. Voor het realiseren van een gewenst product, in ons geval betrouwbare applicaties, is het relevant om de vraag- en aanbodzijde bij elkaar te brengen. Door bewust gezamenlijk dit onderzoek te doen en daarmee vraag- en aanbodzijde te combineren hopen we tot een evenwichtig onderzoek en resultaat te komen. Voor dit onderzoek zijn wij vanuit onze werkgever begeleid door de heer B. Bokhorst RA RE. Daarnaast heeft de heer Dr. R. Matthijsse RE ons vanuit de VU begeleid. Beide heren willen wij danken voor hun tijd en energie, voor de opbouwende kritiek waardoor we nooit te ver zijn afgedwaald. Zij hielpen ons scherp te blijven in de verschillende fasen van het onderzoek door kritische vragen en opmerkingen. Onze werkgever willen we natuurlijk bedanken voor het bieden van de benodigde faciliteiten met betrekking tot het volgen van deze opleiding. Rene Veenendaal, nr Arnoud Goudbeek, nr Apeldoorn Voorjaar 2011 Versie :

3 INHOUDSOPGAVE 1 AANLEIDING DOEL, SCOPE EN AANPAK VAN HET ONDERZOEK DOELSTELLING SCOPE VAN HET ONDERZOEK AANPAK VOORONDERZOEK GERICHT OP HET ONTWIKKELEN EN ONDERHOUDEN VAN BETROUWBARE APPLICATIES BETROUWBAARHEID VAN EEN SOFTWAREPRODUCT DE SOFTWARE DEVELOPMENT LIFE CYCLE ONDERZOEK NAAR MAATREGELEN CONCEPTUEEL ONDERZOEKSMODEL GEHANTEERDE PRINCIPES VOORGESTELDE MAATREGELEN UITWERKING CASE STUDY INLEIDING BEVINDINGEN ONDERHOUD EN VERNIEUWING BEVINDINGEN VERBINDENDE PROCESSEN BEVINDINGEN KWALITEITSMANAGEMENT ANALYSE CONCLUSIE AANBEVELINGEN ONDERZOEKSVRAGEN EN BEANTWOORDING NAWOORD BRONNEN BIJLAGEN DEFINITIES EN SYNONIEMEN ISO BESCHRIJVING OWASP PRINCIPES BESCHRIJVING BEVEILIGINGSPRINCIPES D. ROOK SANS TOP 25 SOFTWARE FOUTEN OWASP TOP 10 RISICO S Versie :

4 1 AANLEIDING In de huidige bedrijfsvoering van organisaties worden de bedrijfsprocessen ondersteund door informatiesystemen. Deze informatiesystemen bestaan steeds meer uit web-based applicaties. De bedrijfsvoering is in grote mate afhankelijk geworden van de betrouwbaarheid van (web)applicaties. Uit marktonderzoek 1 blijkt dat in software ontwikkeltrajecten steeds weer, vaak dezelfde, fouten worden gemaakt. Een paar voorbeelden wat de gevolgen kunnen zijn. Twee fouten uit de top 25 van SANS lagen samen ten grondslag aan het misbruik van 1,5 miljoen websites over het jaar 2008, variërend van het down -gaan tot diefstal van persoonlijke en financiële informatie van bezoekers. (bron Automatiseringsgids ) Nederlandse experts hebben 84 lekken in software voor hogescholen en universiteiten ontdekt. Studenten kunnen cijfers aanpassen, terwijl hun privacy gevaar loopt. Veel fouten worden maar niet gedicht. Onderzoekers Jobert Abma en Michiel Prins van het beveiligingsbedrijf Online24 deden onderzoek naar de beveiliging van Blackboard academic suite, de de facto marktleider op het gebied van e-learning voor scholen en universiteiten. In totaal ontdekten zij 84 lekken. (bron Webwereld ) De door SANS 2 en OWASP 3 gepubliceerde fouten kunnen leiden tot grote verstoringen in de applicaties die de bedrijfsprocessen van een organisatie ondersteunen en hebben tevens impact op het imago van deze organisaties. Daarom zijn wij verbaasd dat organisaties blijkbaar nog geen afdoende antwoord gevonden hebben op deze fouten. Hoe gaat de IT-auditor om met dit gegeven? Hiervoor refereren we aan een publicatie van Prof. Dr. C. Verhoef die stelt dat het realisatietraject van softwareontwikkeling ook onder een audit regime geplaatst moet worden 4. Veel IT-audit inspanning vindt nu plaats ten behoeve van de 1 en 2 SANS = SysAdmin Audit, Network, Security 3 OWASP = Open Web Application Security Program 4 Versie :

5 jaarrekeningcontrole. Belangrijk onderdeel hierbij zijn de general-it controls die gehanteerd worden in de exploitatiefase. Motivatie voor een audit regime op het realisatietraject is het verkrijgen van zekerheid ten aanzien van het aspect betrouwbaarheid van een applicatie. Wij zijn nieuwsgierig of er vanuit de literatuur oplossingen gevonden kunnen worden om te voorkomen dat deze fouten worden gemaakt. Als we oplossingen hebben gevonden kunnen deze bijdragen aan het voorkomen van verstoringen in applicaties van organisaties. Tevens kan dit een handvat zijn voor de IT-auditor bij het geven van een oordeel over het software ontwikkeltraject. De verbazing over de herhaald gemaakte fouten, nieuwsgierigheid hoe dit voorkomen kan worden en relevantie voor organisaties en IT-auditors hebben geleid tot de keuze van dit onderwerp voor ons afstudeeronderzoek in het kader van onze opleiding tot IT-auditor aan de VU-Amsterdam. Versie :

6 2 DOEL, SCOPE EN AANPAK VAN HET ONDERZOEK 2.1 DOELSTELLING Met dit onderzoek willen we een bijdrage leveren, middels een stelsel van maatregelen, aan het realiseren en onderhouden van kwalitatief betrouwbare applicaties. Centrale onderzoeksvraag: Welke elementen en kenmerken bevat een Software Development Life Cycle (SDLC) waarmee met name het realiseren en onderhouden van betrouwbare applicaties wordt ondersteund? Doelgroep Het resultaat van het onderzoek zal voor twee doelgroepen bruikbaar zijn. Het management dat verantwoordelijk is voor het realiseren en onderhouden van betrouwbare applicaties en ITauditors die het framework als audit instrument, normenkader, kunnen gebruiken in hun werk. Deelvragen De centrale onderzoeksvraag wordt uitgesplitst naar de volgende drie deelvragen: 1.) Waaruit bestaat de Software Development Life Cycle en welke risico s met betrekking tot betrouwbaarheid zijn daarin te onderkennen? Vanuit de literatuur wordt gekeken uit welke processtappen een SDLC is opgebouwd. Tevens wordt onderzocht welke risico s er onderkend kunnen worden bij het realiseren en onderhouden van betrouwbare applicaties. 2.) Welke maatregelen dienen genomen te worden in de SDLC om de betrouwbaarheid van applicaties te beheersen? Wanneer duidelijk is welke risico s er kunnen bestaan binnen de SDLC, wordt vanuit de literatuur gekeken naar maatregelen die een positieve bijdrage leveren aan het voorkomen hiervan, deze worden dan samengevoegd in een conceptueel model. Versie :

7 3.) Zijn de voorgestelde maatregelen toepasbaar in de praktijk en wat zijn de bevindingen? Door middel van expert gesprekken willen we onderzoeken of het conceptueel model als relevant en toepasbaar wordt beschouwd door specialisten. Dit onderzoek voeren wij uit binnen een zeer groot softwarebedrijf waar gebruik wordt gemaakt van diverse technologie platformen en programmeertalen. 2.2 SCOPE VAN HET ONDERZOEK Productview Bij softwareontwikkeling kunnen verschillende soorten software worden gemaakt, wij richten ons in dit onderzoek echter op applicaties. Onder een applicatie wordt toepassingssoftware verstaan dat onderdeel uitmaakt van een informatiesysteem. Een applicatie levert vanuit het informatiesysteem ondersteuning aan één of meer bedrijfsprocessen, daarom soms aangeduid als businessapplicatie. 4-lagen model B. Betz In het vierlagenmodel van Betz wordt applicatie aangegeven met het begrip toepassing in de laag informatiesystemen. Versie :

8 De scope met betrekking tot de applicatie ligt op het kwaliteitsaspect betrouwbaarheid, wat we hieronder verstaan wordt onderzocht en toegelicht in hoofdstuk 3. Procesview De software development life cycle bestaat uit een aantal processtappen. Voor dit onderzoek wordt gebruik gemaakt van de processtappen beschreven volgens Application Service Library (ASL), dit is een best practice voor software ontwikkeling en beheer. Door gebruik te maken van het ASL-kader sluit dit onderzoek aan bij de praktijk en zullen de verschillende processtappen herkenbaar zijn voor betrokken partijen. 2.3 AANPAK Vooronderzoek Dit onderzoek begint met een theoretisch vooronderzoek. De fouten die in de aanleiding worden genoemd zijn symptomen van het feit dat in het proces van applicatieontwikkeling niet voldoende aandacht is geweest voor betrouwbaarheid in het algemeen en deze fouten. Daarom zijn er ook geen afdoende maatregelen zijn getroffen in het ontwikkel en beheer proces. SANS 5 publiceert de top 25 van softwarefouten, echter de complete lijst bestaat uit ruim 800 softwarefouten. In het kader van dit onderzoek zoeken we naar algemene maatregelen waarmee we een basis kunnen leggen voor het conceptueel model. Deze maatregelen zullen voor een groot deel leiden naar te hanteren principes, waarmee ook de individuele fouten kunnen worden voorkomen. De uitkomst van het proces van applicatieontwikkeling is een gerealiseerde applicatie. De focus zal daarom gelegd moeten worden bij procesbeheersing, waarbij tevens aandacht moet zijn voor de productkwaliteit en voor de rol van de mens in het proces. Opzet van het conceptueel model We willen het conceptueel model zodanig inrichten dat het voor een IT-organisatie helder is op welke manier de kans op het realiseren van onbetrouwbare applicaties is te verkleinen. Tevens willen we bereiken dat een IT-auditor een voldoende handvat heeft om het software ontwikkeltraject te kunnen beoordelen op het aspect betrouwbaarheid. 5 Versie :

9 De case study Input voor de case study is het vanuit het theoretisch vooronderzoek opgestelde conceptueel model. Dit model zal via gesprekken met experts in het vakgebied kritisch worden beschouwd waarbij volledigheid, diepgang en toepasbaarheid aandachtspunten zullen zijn. Het conceptueel model zal met name worden beoordeeld op toepasbaarheid. Omdat we een zo breed mogelijk commentaar willen hebben willen we spreken met managers, architecten, bouwers, testers, kwaliteitsadviseurs en IT-auditors. De case study zal uitgevoerd worden binnen een groot softwarebedrijf dat gebruik maakt van verschillende platformen en programmeertalen. Documentatie De bevindingen van het onderzoek zijn gedocumenteerd in deze scriptie. Versie :

10 3 VOORONDERZOEK GERICHT OP HET ONTWIKKELEN EN ONDERHOUDEN VAN BETROUWBARE APPLICATIES Dit hoofdstuk richt zich op het vooronderzoek en bestaat uit drie onderdelen. Als eerste wordt het begrip betrouwbaarheid nader beschouwd. Omdat het hier om een kwaliteitskenmerk van een product gaat wordt de internationale ISO-norm 9126 gehanteerd. Vervolgens wordt het proces van softwareontwikkeling en onderhoud nader beschouwd op basis van het ASLframework. Als laatste wordt gekeken naar risico s die zich in het proces kunnen voordoen dit in relatie tot het gewenst doel, productkwaliteit. 3.1 BETROUWBAARHEID VAN EEN SOFTWAREPRODUCT Als het doel is om betrouwbare applicaties te ontwikkelen en te onderhouden, dan is het van belang om het kwaliteitsbegrip betrouwbaarheid nader te beschouwen vooral omdat er diverse invalshoeken zijn om dit begrip te definiëren. Voor dit onderzoek wordt betrouwbaarheid zowel vanuit het vakgebied IT-auditing als vanuit het product benaderd. IT-auditing Informatie verwerking door een applicatie dient vanuit het bedrijfsproces gezien betrouwbaar te zijn. Betrouwbaarheid richt zich dan op het integer en vertrouwelijk behandelen van gegevens, tevens dienen de gegevens op de juiste momenten beschikbaar te zijn. Betrouwbaarheid is hier een kwaliteitseis gericht op de functionaliteit informatieverwerking. Binnen het IT-audit vakgebied spreekt men dan over confidentiality, integrity en availability (CIA) ISO 9126 Betrouwbaarheid van een applicatie is een kwaliteitskenmerk van het product software. Voor softwarekwaliteit is de internationale ISO-norm 9126 beschikbaar als kader, we gebruiken dit kader ook voor ons onderzoek. In onderstaande figuur is een overzicht gegeven van de kwaliteitskenmerken die binnen deze ISO-norm worden onderkend. Versie :

11 Kenmerken van betrouwbaarheid Betrouwbaarheid bestaat binnen de ISO-norm 9126 uit vijf subkenmerken. Omdat we de relatie leggen met CIA vinden we het begrip betrouwbaarheid volgens de ISO-norm voor ons onderzoek te eng gedefinieerd. We missen met name delen uit de hoofdkenmerken functionaliteit en onderhoudbaarheid. Daarom kiezen wij ervoor om het begrip betrouwbaarheid voor dit onderzoek als volgt uit te breiden. Onderhoudbaarheid Het kwaliteitskenmerk onderhoudbaarheid richt zich op de onderhoudsperiode in de SDLC en is relevant voor het onderzoek. De subkenmerken gegroepeerd binnen dit kwaliteitskenmerk richten zich vooral op efficiënt en effectief onderhoud, hiervoor is transparantie en beperking van complexiteit nodig. Deze aspecten hebben tevens een positief effect op betrouwbaarheid in het algemeen, we denken hierbij aan het voorkomen van security by obscurity. Het realiseren van een betrouwbare applicatie stopt niet bij de ontwikkeling. Veranderende omstandigheden bijvoorbeeld vanuit de bedrijfsprocessen of vanuit nieuw opgekomen technische risico s kunnen een reden zijn om de applicatie aan te passen. Hier moet bij de ontwikkeling van de applicatie al rekening mee worden gehouden De kenmerken stabiliteit, wijzigbaarheid, testbaarheid en beheerbaarheid vormen vereisten voor deze veranderingen. Versie :

12 Functionaliteit Vanuit het kenmerk functionaliteit dragen de subkenmerken juistheid en beveiligbaarheid bij aan betrouwbaarheid, met name vanuit de optiek van de vraagzijde. Juistheid moet de feitelijk juiste verwerking van gegevens (application controls) waarborgen en beveiligbaarheid heeft invloed op alle drie de aspecten van CIA. Voor beide subkenmerken is het uitermate belangrijk om goed te programmeren, omdat blijkt dat veel van de gemaakte softwarefouten zoals gepubliceerd door SANS te maken hebben met deze subkenmerken. Vanuit het totaal van de kwaliteitskenmerken van ISO 9126 komen wij voor dit onderzoek tot de volgende set subkenmerken die een bijdrage leveren aan de betrouwbaarheid van een applicatie. Kenmerk 6 Engels Definitie Synoniemen en verwante begrippen Volwassenheid maturity Mate waarin fouten en kinderziektes verholpen zijn en het systeem vrij blijft van storingen Bedrijfszekerheid, Stabiliteit, Stabiliteit bij veranderingen Foutbestendigheid fault tolerance Mate waarin het systeem bestendig is tegen bedoeld of onbedoeld onjuist gebruik en tegen fouten in aanpalende systemen Robuustheid, Bestendigheid Fouttolerantie Beschikbaarheid availability Mate waarin het systeem op de gewenste tijden beschikbaar is voor de gebruiker Degradeerbaarheid degradability Mate waarin de essentiële functies van het systeem blijven functioneren tijdens en na storingen Zelfherstellend vermogen, Veerkracht Herstelbaarheid recoverability Gemak waarmee het systeem na uitval weer operationeel te maken is, zonder gegevensverlies Beveiligbaarheid Security Mate waarin opzettelijk of abusievelijk ongeoorloofde toegang wordt voorkomen Beveiliging Juistheid accuracy Juistheid van de uitvoer van het systeem, Nauwkeurigheid, 6 Voor een volledige lijst met definities wordt verwezen naar bijlage 9.1 Versie :

13 Kenmerk 6 Engels Definitie Synoniemen en verwante begrippen overeenkomstig de invoer en de gespecificeerde bewerkingen. Plausibiliteit, Datakwaliteit Stabiliteit Stability Mate waarin onbedoelde effecten uitblijven na wijzigingen aan het systeem Testbaarheid testability Gemak waarmee de juiste werking getest en gevalideerd kan worden Beheerbaarheid manageability Gemak waarmee het systeem in operationele staat gebracht en gehouden kan worden. Supportability, Exploiteerbaarheid Wijzigbaarheid changeability Gemak waarmee het systeem gecorrigeerd, gewijzigd en verbeterd kan worden. Corrigeerbaarheid, Veranderbaarheid 3.2 DE SOFTWARE DEVELOPMENT LIFE CYCLE. Het softwareontwikkel- en onderhoudsproces bestaat uit een groot aantal activiteiten die te groeperen zijn naar een aantal hoofdprocessen. Een beschrijving van deze hoofdprocessen en activiteiten is te vinden in het Application Service Library (ASL 7 ) framework. ASL is een procesframework voor applicatiemanagement. Op basis van het ASL-framework en mogelijke risico s ten aanzien van betrouwbaarheid, wordt in dit hoofdstuk antwoord gegeven op de eerste deelvraag namelijk; 1.) Waaruit bestaat de Software Development Life Cycle en welke risico s met betrekking tot betrouwbaarheid zijn daarin te onderkennen? Application Service Library ASL beschrijft een framework voor de processen van applicatiemanagement. Als framework sluit ASL aan bij andere frameworks zoals ITIL voor beheer en exploitatie van de IT infrastructuur en BiSL voor business informationmanagement. 7 Bron: ASL 2 Een framework voor applicatiemanagement (ISBN ) Versie :

14 In bovenstaande figuur zien we dat het ASL-framework is onderverdeeld in drie lagen. OCM 8 en ACM 9 richten zich vooral op de toekomst van organisatie en applicatie met als doel afstemming en verbetering van dienstverlening. Het zijn als zodanig de strategische processen binnen ASL. Vervolgens is er een laag met sturende processen, deze processen vormen een brug tussen operationele en richtinggevende processen. De operationele laag bestaat uit de processen Beheer, Verbinden en Onderhoud & Vernieuwing. Of en hoever de ASL processen zijn uitgewerkt zal per organisatie verschillen. Uitgaande van organisaties die zelf software ontwikkelen, ligt het voor de hand dat zij minimaal een deel van de operationele processen hebben ingericht. Voor het onderzoek richten wij ons op de volgende drie clusters: Onderhoud en vernieuwing Verbindende processen Kwaliteitsmanagement 8 OCM = Organization Cycle Management 9 ACM = Application Cycle Management Versie :

15 Onderhoud en vernieuwing Impactanalyse Voordat een applicatie wordt ontworpen of een significante wijziging moet ondergaan, dient de impact hiervan te worden bepaald. Er zijn drie domeinen waarop de wijziging (nieuw of aanpassing) invloed heeft. Het eerste domein is de vraagzijde. Voor de vraagzijde kan de wijziging invloed hebben op het uitvoeren van het betreffende bedrijfsproces waar de applicatie een bijdrage aan levert. Bijvoorbeeld het invoeren van een online reserveringssysteem voor vliegtuigstoelen leidt er toe dat klanten dit zelf kunnen en minder fysiek gebruik zullen maken van het reisbureau. Het tweede domein is de gebruikte infrastructuur. Wijzigingen in het applicatielandschap kunnen grote impact hebben op de onderliggende infrastructuur. Van online applicaties wordt meestal een 7*24uur beschikbaarheid geëist met voldoende performance. De infrastructuur zal daarop ingericht moeten worden. Het derde domein is de applicatie zelf. Hoeveel inspanning zal het vergen om de applicatie te realiseren of te wijzigen en wat betekent dit voor het onderhoud? Welke technologie past het best bij de gewenste functionaliteit en hoe is de betrouwbaarheid hiervan geregeld? Vanuit de drie domeinen zal de impactanalyse zich moeten richten op de risico s ten aanzien van het kwaliteitsaspect betrouwbaarheid. Deze risico s moeten worden bijgehouden in een risk register 10, zodat er een overzicht is van de te beheersen risico s. Uit met name de productie fase, waar nieuwe bedreigingen kunnen ontstaan, komen signalen waarmee het risk register moet worden gevuld om actueel te blijven. Men loopt het risico dat het risk register niet altijd actueel is, dit kan verschillende oorzaken hebben bijvoorbeeld door het feit dat er nieuwe technologie gebruikt gaat worden waarbij de risico s nog onbekend zijn. Of door virtualisatie van infrastructuur kan er onduidelijkheid bestaan welk deel van de infrastructuur betrokken moet worden in de analyse. Tevens kan de complexiteit van de code zelf oorzaak zijn van het niet goed kunnen inschatten van de risico s. Samenvattend onderkennen we de volgende risico s; - Nieuwe technologie brengt nieuwe (nog) onbekende risico s met zich mee voor het bedrijfsproces; - Onduidelijkheid over welke infrastructuur gebruikt wordt door de applicatie; - Complexiteit van de applicatie zelf, waardoor impact van een wijziging moeilijk is vast te stellen. 10 College documentatie : Framework for application an d data security Versie :

16 Ontwerpproces De eerste stap naar realisatie is het in functionele termen duidelijk maken wat de, door de vraagzijde, gewenste functionaliteit inhoud. Dit Functionele Ontwerp (FO) dient voor de vraagzijde als ook voor de aanbodzijde voldoende duidelijk te zijn. In feit komen business en IT hier samen. Naast het beschrijven van de gebruikers/business-functionaliteit, dienen er in deze fase ook kwaliteitseisen te worden gesteld aan de applicatie, zoals performance, onderhoudbaarheid en betrouwbaarheid. Ook dit is in het belang van de vraagzijde, want om een bedrijfsproces betrouwbaar uit te kunnen voeren, is een betrouwbare applicatie nodig. Deze kwaliteitseisen richten zich op de gehele life-cycle van de applicatie en dwingen daarmee maatregelen af om risico s (risk register) te voorkomen. Dit geldt voor de applicatie, een goed onderhoudbare applicatie is effectief en efficiënt aan te passen aan gewijzigde omstandigheden. En het geldt ook voor de onderliggende infrastructuur, de verantwoordelijke voor het beheer en onderhoud van de infrastructuur zal bijvoorbeeld kunnen eisen dat applicaties geen hoge rechten nodig hebben op de infrastructuur, omdat deze ongewenste effecten kunnen hebben op de beschikbaarheid van die infrastructuur. Kortom, zowel de vraagzijde als de aanbodzijde (applicatief en infrastructureel) zullen voor realisatie, onderhoud en beheer eisen hebben vanuit hun verantwoordelijkheid om uiteindelijk de functionaliteit te kunnen realiseren en te onderhouden waarbij de risico s geminimaliseerd zijn. Dit programma van eisen (PvE) vormt input voor het Functioneel Ontwerp. Het risico bestaat echter dat betrouwbaarheidseisen niet of onvoldoende worden gesteld, waardoor betrouwbaarheid niet mee wordt ontwikkeld met de gebruikers/businessfunctionaliteit. Dit kan verschillende oorzaken hebben, bijvoorbeeld omdat de vraagzijde niet in staat blijkt te zijn om deze eisen te specificeren. Vaak is er wel veel aandacht voor infrastructurele eisen maar blijft de kwaliteit van software onderbelicht. Dit terwijl uit onderzoek 11 blijkt dat de betrouwbaarheidsrisico s in applicaties steeds groter worden ten opzichte van infrastructuur. Samenvattend onderkennen we de volgende risico s; - Het PvE bevat geen specificaties omtrent betrouwbaarheid; - Vraagzijde is onvoldoende betrokken, of niet capabel om de juiste eisen te stellen; - Betrouwbaarheid wordt niet mee ontworpen, gerelateerd naar application controls, general IT-controls en softwarekwaliteit. 11 Zie Versie :

17 Realisatieproces Het realisatieproces volgt op het functioneel ontwerp en is in twee fasen te onderscheiden. Als eerste zal het FO omgezet moeten worden naar een Technisch Ontwerp (TO), het wat (functionaliteit) wordt vertaald naar het hoe (techniek). Bij het maken van het technisch ontwerp zal op basis van standaarden, technologie, voorschriften, principes en methoden keuzes worden gemaakt hoe de functionaliteit middels IT wordt gerealiseerd. Deze keuzes hebben betrekking op zowel de software als de onderliggende infrastructuur. Maatregelen om risico s te verkleinen kunnen in de applicatie en de infrastructuur worden genomen, volgens het principe security in depth. Betrouwbaarheid van webapplicaties bijvoorbeeld wordt idealiter deels in de infrastructuur (o.a. platform hardening en DMZ 12 ) en deels in de applicatie gerealiseerd (secure coding) Op basis van de keuzes die gemaakt zijn in het TO kunnen softwarespecialisten de applicatie gaan realiseren. In deze fase wordt het technisch ontwerp geconcretiseerd in softwaretechnologie, bijvoorbeeld.net, JAVA, C of Cobol. Afhankelijk van de gebruikte technologie kan men tools gebruiken om code te genereren, bijvoorbeeld Google Web Toolkit voor JAVA, of delen van code downloaden van het internet. Risico in het realisatieproces begint bij het onvoldoende richting en inhoud geven aan het aspect betrouwbaarheid, bijvoorbeeld vanuit de architectuur. Dit zal er toe leiden dat betrouwbaarheid onvoldoende wordt mee ontworpen op basis van best practices, polices en ontwerpprincipes, waarmee de kwaliteit van het ontwerp te afhankelijk wordt van de kennis en kunde van een individuele ontwerper. Onvoldoende afstemming met infrastructuur leidt er toe dat maatregelen niet genomen worden of niet op elkaar aansluiten. Hierdoor wordt aan een principe als defense in depth onvoldoende inhoud gegeven. Bij het feitelijk realiseren/genereren van de code kan er onvoldoende aandacht zijn voor secure coding. Hierdoor ontstaan zwakheden in de applicatie waardoor de betrouwbaarheid afneemt. Samenvattend onderkennen we de volgende risico s; - Er wordt geen of onvoldoende richting gegeven in het technisch ontwerp aan het kwaliteitsaspect betrouwbaarheid voor de te bouwen applicatie; - Onvoldoende afstemming met infrastructuur over invulling betrouwbaarheid; - De applicatiesoftware bevat programmeerfouten die kwetsbaarheden in de betrouwbaarheid veroorzaken. 12 DMZ = DeMilitarized Zone Versie :

18 Testproces Tijdens het testproces dient te worden vastgesteld dat datgene wat ontworpen is ook gerealiseerd is. Voor het uitvoeren van testen worden diverse test sets gemaakt en onderhouden. Testen gericht op het nog steeds goed functioneren van bestaande functionaliteit bij wijzigingen, regressie testen, of testen gericht op samenwerking met andere delen, integratie testen. Testen dienen ook gericht te zijn op kwaliteitseisen, voor dit onderzoek op betrouwbaarheid. Test sets zijn dan afgestemd op de risico s uit het risk register ten aan zien van betrouwbaarheid. Middels penetratietesten kan men beoordelen of maatregelen tegen misbruik afdoende zijn. Wanneer men alleen test op het eindresultaat loopt men het risico dat er pas in een (te) laat stadium wordt vastgesteld dat het eindproduct niet voldoet aan de eisen. Des te eerder fouten worden ontdekt des te lager de herstelkosten zullen zijn en des te makkelijker is een fout te herstellen is. Daarom worden er idealiter toetsen uitgevoerd in de ontwerp- en realisatiefase op tussenproducten zoals een FO, TO en code. Naast het feit dat de testen inhoudelijk relevant moeten zijn, dient de omgeving productie like (infra, software en autorisaties) te zijn om tot valide testresultaten te komen. Daarnaast dient er een strategie te zijn hoe in het testproces wordt omgegaan met patches van de leverancier. Met name bij security updates is snelheid geboden om kwetsbaarheden te verhelpen. De snelheid van uitrol naar productie kan op gespannen voet staan met een afdoende testtraject. Samenvattend onderkennen we de volgende risico s; - Testspecificaties en testontwerp is vanuit ontwerp en realisatie niet meegenomen; - Testen richt zich niet of onvoldoende op het kwaliteitsaspect betrouwbaarheid; - Testomgeving sluit onvoldoende aan op productie omgeving; - Software updates van leveranciers worden niet zelf getest. Implementatieproces In het voorgaande testproces is idealiter aangetoond dat de applicatie is gerealiseerd volgens het technisch ontwerp. Echter door de ontvangende partijen zal nog moeten worden vastgesteld dat het resultaat ook voldoet aan het functioneel ontwerp inclusief het programma van eisen. De ontvangende partij naast de vraagzijde is de aanbodzijde in de rol van technisch applicatiebeheer en beheer infrastructuur. Alle drie de partijen hebben vanuit hun verantwoordelijkheid eisen gesteld aan de applicatie. Tijdens het implementatieproces moeten zij vaststellen dat er maatregelen getroffen zijn en dat die functioneren om de onderkende risico s te mitigeren. Om dit te kunnen vaststellen voeren de drie partijen acceptatietesten uit in een speciaal hiervoor ingerichte omgeving. De aanbodzijde, in de rol van softwareleverancier, levert ondersteuning bij het uitvoeren van deze acceptatietesten. Versie :

19 Risico s bij de acceptatietesten zijn vergelijkbaar met de risico s in het testproces bij de ontwikkeling. Ook hier geldt bijvoorbeeld dat de acceptatieomgeving productie like moet zijn. Zodra de applicatie door de verschillende partijen is geaccepteerd, is deze klaar om in productie genomen te worden. Om dit traject gecontroleerd te laten verlopen zijn er binnen ASL twee verbindende processen benoemd. Samenvattend onderkennen we het volgende risico. - Ondersteuning en acceptatie vindt niet of onvoldoende plaats met betrekking tot betrouwbaarheidseisen (volgens het programma van eisen) Verbindende processen Wijzigingenbeheer Wijzigingen hebben tot doel een applicatie te verbeteren, echter er schuilt ook een risico in het doorvoeren van een wijziging namelijk het optreden van incidenten in het algemeen en daarmee ook op het punt van betrouwbaarheid. Het is daarom van belang dat wijzigingen heel gecontroleerd worden uitgevoerd. Vooraf dient duidelijk te zijn wat het nut en de noodzaak is van een wijziging en wat de impact kan zijn voor de eerder genoemde drie domeinen (vraagzijde, aanbodzijde en infrastructuur) Wijzigingen dienen hierop te worden beoordeeld door het CAB 13 voordat een wijziging geautoriseerd is om doorgevoerd te kunnen worden. Wijzigingen in software zijn in verschillende soorten te onderscheiden zoals een release, een patch of een technische update (leverancier) Het is van belang om deze verschillende type wijzigingen te onderkennen omdat de omvang, impact, urgentie hiervan verschillend is en dat daar de controlemaatregelen en goedkeuring op dienen te zijn afgestemd. Hoe gaat men bijvoorbeeld om met een update van JAVA, is dit een standaard wijziging of niet? Dit bepaald mede hoe de wijziging behandeld moet worden binnen wijzigingenbeheer. Omdat er bij het doorvoeren van een wijziging altijd het risico blijft bestaan dat er iets misloopt, met een onacceptabele impact voor één of meer domeinen, zal de behoefte bestaan om terug te gaan naar de oude situatie. Om dit mogelijk te maken zal een roll-back scenario ontworpen en getest moeten worden. Bij de impactanalyse zal bepaald worden of deze maatregel dient te worden getroffen. Belangrijk is het risico dat wijzigingen kunnen plaatsvinden buiten het proces wijzigingenbeheer om. Hierdoor kunnen diverse risico s direct en op een later tijdstip ontstaan doordat geen zekerheid meer bestaat over de actuele situatie van de software. De integriteit kan 13 CAB = Change Advisory Board Versie :

20 niet meer worden gewaarborgd. Dit risico ontstaat bijvoorbeeld wanneer programmeurs, inclusief hun autorisaties, een incident moeten oplossen in de productieomgeving. Samenvattend onderkennen we de volgende risico s - Het risico van een wijziging op het kwaliteitsaspect betrouwbaarheid wordt niet of onvoldoende beoordeeld door het CAB 14 ; - Wijzigingen kunnen buiten het proces om plaatsvinden; - Roll-back van een wijziging ontbreekt. Programmabeheer en distributie De applicatie (wijziging) is nu zover dat deze in productie kan worden genomen. Ook hier geldt dat dit op een gecontroleerde wijze moet gebeuren. Alleen geautoriseerde wijzigingen mogen doorgevoerd worden en indien nodig zal er een roll-back scenario beschikbaar moeten zijn. Ook het tijdsstip van distributie is van belang, moet het in een servicewindow of mag het er ook buiten. De software zal gedistribueerd moeten worden over de verschillende servers. Hierbij is het van belang dat de nieuwe software aansluit op de aanwezige software. Inzicht in welke software (release/patch-niveau) waar geïnstalleerd is, is hierbij van cruciaal belang. Hiervoor dient een actuele software bibliotheek per OTAP-omgeving beschikbaar te zijn. Foutieve distributie kan er bijvoorbeeld toe leiden dat men oude problemen terug krijgt omdat er in plaats van nieuwe, oude software is gedistribueerd. Het is tevens van belang dat de OTA- en P-omgeving voldoende van elkaar zijn gescheiden zodat er niet ongecontroleerd software gedistribueerd wordt naar servers in de productieomgeving terwijl de distributie alleen bestemd was voor de servers in de acceptatieomgeving. Samenvattend onderkennen we de volgende risico s - Versiebeheer in de verschillende omgevingen (OTAP 15 ) niet juist en volledig; - Er is onvoldoende scheiding tussen verschillende omgevingen binnen OTAP. 14 Change Advisory Board (Change proces ITIL) 15 OTAP = Ontwikkel Test Acceptatie Productie Versie :

21 Sturende proces Kwaliteitsmanagement Binnen ASL draagt het sturende proces kwaliteitsmanagement zorg voor de kwaliteit van product, proces, organisatie en middelen. De productkwaliteit hebben wij in ons onderzoek gedefinieerd aan de hand van geselecteerde kenmerken uit ISO De proceskwaliteit wordt bepaald door de kwaliteit van de inrichting, de rollen en verantwoordelijkheden en evaluatie van het proces, waarbij het streven moet zijn het proces te blijven verbeteren. De organisatiekwaliteit richt zich op zaken als kwaliteit van mensen, expertises en opleidingen Daarnaast vinden wij dat ook de visie, strategie en doelstellingen van een organisatie relevant zijn, omdat op basis daarvan sturing zal plaatsvinden op productkwaliteit, risicoacceptatie, expertise en opleidingen. Goed gereedschap (MTHV s) vormt een randvoorwaarde om goede producten effectief en efficiënt te kunnen realiseren. Hierbij kan men denken aan ontwikkelstraten die afgestemd zijn op de gebruikte technologie en de verschillende OTAP-omgevingen. Met name bij de OTAPomgeving zijn twee zaken van belang. Allereerst dienen de verschillende omgevingen voldoende logisch gescheiden te zijn zodat er eenduidigheid bestaat over waar het tussenproduct zich bevindt. Daarnaast dienen autorisaties(functiescheiding) en het gebruik daarvan (professionaliteit) in lijn te zijn met de scheiding tussen de OTAP-omgeving. Hiermee voorkomt men dat er onrechtmatige wijzigingen kunnen plaatsvinden op tussenproducten. Met andere woorden de integriteit van zowel de omgeving als het product dient gewaarborgd te zijn. Tevens is het van belang dat beleid voldoende geoperationaliseerd is naar MTHV s zodat specialisten gefaciliteerd worden in de effectieve en efficiënte uitvoering hiervan. Het goed sturen op het gebruik van de MTHV s kan preventief werken ten aanzien van het falen van de mens. Samenvattend onderkennen we de volgende risico s - Management geeft geen richting middels visie, strategie en doelstelling t.a.v. betrouwbaarheid; - Medewerkers zijn onbewust onbekwaam wanneer het gaat om betrouwbaarheid en het realiseren daarvan in software; - Beleidskader is niet of onvoldoende geoperationaliseerd naar MTHV s; - Er wordt niet goed gestuurd op het gebruik van MTHV s; - Functiescheiding is onvoldoende; - Rollen en verantwoordelijkheden zijn niet duidelijk belegd in de organisatie. Versie :

22 3.3 ONDERZOEK NAAR MAATREGELEN Voor de maatregelen zijn vanuit de literatuurstudie een aantal bronnen geselecteerd. De criteria die bij het selecteren van deze bronnen zijn gebruikt zijn openheid, actualiteit en validiteit. Daarnaast is er gezocht naar een evenwichtige verdeling met betrekking tot proces, product en personeel. De maatregelen moeten er in resulteren dat wordt voldaan aan de geselecteerde kenmerken van ISO 9126 en dat daarmee een betrouwbare applicatie kan worden gerealiseerd. Software Assurance Maturity Model (SAMM) SAMM is een maturity model voor software waarbij openheid en realiteitszin twee belangrijke uitgangspunten zijn. Het model werkt vanuit vier business functions via security practices naar activities en heeft als scope software development in brede zin. Eenvoudig, goed gedefinieerd en meetbaar zijn belangrijke principes binnen SAMM. De business functions sluiten aan op de processtappen van ASL. Governance sluit aan bij het sturende proces kwaliteitsmanagement construction heeft een relatie met de processen ontwerp en realisatie, verification met het testproces en deployment heeft een relatie met de verbindende processen van ASL en sluit aan bij de Impactanalyse. Vanuit de relatie met de processen van ASL selecteren we maatregelen die we kunnen gebruiken in het conceptueel model. Building Security In Maturity Model (BSIMM) BSIMM is een volwassenheidsmodel specifiek voor het realiseren van betrouwbare software. BSIMM noemt twee, voor dit onderzoek relevante, doelstellingen namelijk Increased code quality en Clarity on what is the right thing to do for everyone involved in software security. De eerste doelstelling sluit aan op productkwaliteit en de twee de geeft aan dat men in het Versie :

23 proces maatregelen moet nemen om de menselijke fouten te beteugelen.het model levert daarmee een bijdrage aan de product- en proceskwaliteit en heeft oog voor de menselijke factor. Binnen BSIMM worden vier aandachtsgebieden (domains) gedefinieerd, vergelijkbaar met de business functions van SAMM. Binnen deze aandachtsgebieden worden op basis van doelstellingen drie hoofdactiviteiten genoemd. De hoofdactiviteiten worden vervolgens in drie volwassenheidsniveaus verdeeld. De maatregelen die in BSIMM worden genoemd overlappen qua strekking grotendeels de maatregelen van SAMM. BSIMM is echter aanvullend op de volgende punten. Het belang van commitment op senior management niveau wordt genoemd en de rol van het management om dit over te brengen op het overige personeel. Tevens stelt BSIMM een Software Security Group (SSG) voor die qua kennis en kunde een autoriteit is op het vakgebied en van daaruit zowel uitvoerende, beoordelende en adviserende taken heeft. De SSG heeft als klankbord de Satellite die wordt gevormd door ontwikkelaars met interesse voor software beveiliging. Ontwikkel- en beveiligingsprincipes Secure development principles (D. Rook) SANS en OWASP geven inzicht waar risico s zich bevinden en waar fouten gemaakt worden. Wanneer het doel secure application development is, dan is het volgens D. Rook niet effectief om software ontwikkelaars tot in detail alle potentiële fouten en risico s te leren kennen. Het voorkomen van programmeerfouten gaat volgens D. Rook effectiever wanneer ontwikkelaars gebruik maken van negen secure ontwerpprincipes. Voor zijn negen principes hanteert hij als basisprincipe KISS (Keep It Short and Simple). Dit idee sluit aan bij de veel gehoorde behoefte aan complexiteitsreductie binnen de IT-wereld. De principes van D. Rook richten zich op de techniek van het ontwerpen en programmeren. De principes zijn algemeen geformuleerd waardoor ze toepasbaar zijn op meerdere ontwikkelmethoden en programmeertalen. Enerzijds is dit een kracht, anderzijds moet de betrokken specialist wel een vertaling maken naar de eigen situatie. De principes maken onderdeel uit van een SSDLC (Secure Software Development Life Cycle), zoals weergegeven in onderstaand figuur. Versie :

24 De ontwerpprincipes van Rook zijn ook te beschouwen als maatregelen op een groot deel van de beveiligingsprincipes van OWASP. Voor een nadere toelichting op de principes wordt verwezen naar de bijlage 9.3. Open Web Application Security Program (OWASP) Naast het feit dat OWASP een top-10 van risico s benoemd ten aanzien van betrouwbaarheid, worden er in relatie tot de risico s ook principes beschreven om de risico s te verkleinen. De principes kunnen worden toegepast in het proces, ook hier geldt dat de principes geoperationaliseerd moeten worden naar de eigen situatie. Door in een zo vroeg mogelijk stadium dit type principes te hanteren wordt betrouwbaarheid direct meegenomen in het ontwerp traject. Hierdoor wordt de kans op fouten al in het begin verkleind. OWASP noemt hiervoor de volgende principes 16. Apply defense in depth Use a positive security model Fail safely Run with least privilege Avoid security by obscurity Keep security simple Detect intrusions Don t trust infrastructure or external services Establish secure defaults Voor een nadere toelichting op de principes wordt verwezen naar bijlage Versie :

25 Beschouwing menselijk handelen Bij zowel BSIMM als SAMM wordt gesproken over de personele aspecten awareness en training. Om de noodzaak hiervan aan te geven en om duidelijk te maken dat hier in het proces expliciet aandacht aan moet worden geschonken raadplegen we twee modellen van buiten het IT werkveld. Ook binnen het vakgebied van softwareontwikkeling zijn mensen (managers en specialisten) een bepalende factor. Deze mensen maken steeds weer dezelfde (programmeer)fouten ondanks dat er kennis in de markt aanwezig is omtrent veel gemaakte fouten. Leren zij dan niet van eigen en/of andermans fouten? Uit onderzoek blijkt dat betrokkenen zich vaak niet realiseren waar de fouten die ze maken toe kunnen leiden 17. De vraag is of zij zich bewust zijn van potentiële softwarefouten en de eigen gemaakte fouten. Bewustwording is de eerste fase volgens het leerproces model van onbewust onbekwaam naar onbewust bekwaam. Zodra men zich bewust is van het feit dat men onbekwaam is (fouten maakt) kan de afweging gemaakt worden of dit een gewenste situatie is, vaak niet. Zodra de behoefte ontstaat aan bekwaamheid zal training en scholing moeten plaatsvinden. Naast het feit dat men dit model kan toepassen op individuen kan het ook op een (software ontwikkel)organisatie als geheel worden toegepast. Kwaliteitsaspecten van het model zijn de mate van bekwaamheid en de mate van bewustheid. Bekwaamheid gebaseerd op kennis(gecertificeerd) en ervaring, die in lijn moet staan met bij de functie belegde verantwoordelijkheden binnen het gehanteerde functiegebouw. Bewustzijn zal indirect vastgesteld moeten worden. Gezien de snelle ontwikkelingen in het vakgebied zullen beide kwaliteitscriteria periodiek onderhouden moeten worden. 17 Psychologische functieleer Dr. J. van Leyden Sr. (ISBN ) Versie :

26 Betrouwbaarheid van applicaties wordt mede bepaald door de integriteit van medewerkers. Openheid en transparantie van en door medewerkers bevordert het bewust zijn en vergroot daarmee de bestuurbaarheid en controleerbaarheid. In het Johari Window worden twee assen gebruikt om deze openheid/transparantie inzichtelijk te maken namelijk bekend bij individu en bekend bij anderen. De kracht ligt in de openheid zodat hierover gesproken kan worden met als doel de kennis, inzicht en vaardigheden bewust te vergroten. Openheid vraagt om het vertrouwen dat collegae en management integer met deze openheid omgaan. Het model van Bateson Binnen BSIMM wordt de belangrijke rol van het management besproken en samengevat als commitment. Het management moet overtuigd zijn van nut en noodzaak van betrouwbare applicaties en deze overtuiging uitdragen (tone at the top). Het model van Bateson bestaat uit zes niveaus, de bovenste drie gaan over niet zichtbare en de onderste drie over zichtbare aspecten van gedrag. De invloed van de aspecten is het grootst van boven naar beneden. Model Bateson (individu) Model Bateson & Dilts (organisatie) Als een manager of specialist overtuigd is van het nut en de noodzaak van betrouwbaarheid dan ligt het in de lijn der verwachting, volgens het model, dat vaardigheden en gedrag zich daar op zullen richten. Andersom geldt dit natuurlijk ook. Het basismodel kent ook een afgeleide voor organisaties, het model van Bateson & Dilts. Projecteren we dit model op het onderzoek dan kan men stellen dat de effectiviteit van betrouwbaarheid mede bepaald wordt door de activiteiten in lagen erboven, waarbij de bovenste lagen de richting en overtuiging bieden voor een organisatie. Gesprek met Arbeid & Organisatie psycholoog Naast het bestuderen van literatuur hebben wij ook een gesprek gehad met Drs. J. de Veer, arbeid & organisatie psycholoog, verbonden als managementadviseur bij de rijksoverheid. Versie :

27 Motivatie voor dit gesprek lag in de vraag waarom mensen gedrag, het maken van softwarefouten, blijven herhalen en wat is daar aan te doen. De reden van herhaling kan verschillend zijn, bijvoorbeeld het feit dat herhaald gedrag ook beloond gedrag is. De beloning hoeft hierbij zeker niet financieel te zijn maar het kan ook aandacht zijn. Het management of de klant kan bijvoorbeeld wel aandacht hebben voor functionaliteit en fouten daarin. De IT-organisatie zal zich naar alle waarschijnlijkheid vervolgens daarop richten en andere fouten (onbewust) blijven maken. Richting geven aan en faciliteren van ander gedrag zijn belangrijke maatregelen om dit te veranderen (bron: Chip Heath & Dan Heath) Dit inzicht sluit vervolgens weer aan bij Bateson en Dilts. Het faciliteren kan bijvoorbeeld vorm gegeven worden door uitdagingen te creëren en positieve resultaten daarop te waarderen en te communiceren. Regelmatig worden bijvoorbeeld specialisten uitgedaagd om, middels een competitie, softwarefouten te vinden. Voorbeelden 18 hiervan worden met enige regelmaat gepubliceerd op dit principe kan ook binnen een organisatie zelf worden toegepast. Uit het vooronderzoek wordt de conclusie getrokken dat maatregelen voor het realiseren van betrouwbare applicaties een breder perspectief beslaan dan techniek. Dit ondanks het feit dat veel gemaakte fouten van technische aard zijn. Door het combineren van de maatregelen vanuit de maturity modellen BSIMM en SAMM, het hanteren van de principes van OWASP en D. Rook en de beschouwing van het menselijk handelen met behulp van Johari, Leerproces en Bateson, kunnen we nu een conceptueel model samenstellen waarmee kan worden voldaan aan de geselecteerde kwaliteitskenmerken met betrekking tot betrouwbaarheid Versie :

28 4 CONCEPTUEEL ONDERZOEKSMODEL Nadat in de vorige hoofdstukken de risico s op betrouwbaarheid in beeld zijn gebracht willen we in dit hoofdstuk antwoord geven op de tweede deelvraag namelijk: Welke maatregelen dienen genomen te worden in de SDLC om de betrouwbaarheid van applicaties te beheersen? Geïnspireerd door D. Rook en Bateson die stelden dat het hanteren van principes de effectiviteit vergroot, hebben wij een vijftal principes gedefinieerd van waaruit de maatregelen zijn samengesteld. Een organisatie zou deze principes ook zelf kunnen hanteren. Het kunnen hanteren van principes is naar ons idee wel mede afhankelijk van de volwassenheid/ professionaliteit van een organisatie. Dit omdat principes geconcretiseerd dienen te worden naar de eigen praktijk. Maatregelen hebben het voordeel dat zij concreter zijn dan principes en kunnen daardoor een organisatie helpen om snel de eerste stappen te zetten in het realiseren en onderhouden van betrouwbare applicaties. Wij willen er wel op wijzen dat maatregelen niet dogmatisch gehanteerd dienen te worden als vinklijstje, uiteindelijk dient elke maatregel een bijdrage te leveren aan de doelstelling. Als een maatregel niet bijdraagt kan men teruggaan naar de gehanteerde principes en het te realiseren doel, om op basis daarvan een betere maatregel te nemen. Door het hanteren van maatregelen en principes binnen een SDLC kan een software ontwikkelen onderhoudsproces uitgroeien richting een Secure-SDLC. Dit begrip komt men steeds vaker tegen in literatuur 19 waarmee aangegeven wordt dat er maatregelen genomen zijn ten behoeve van het realiseren en onderhouden van betrouwbare applicaties. 4.1 GEHANTEERDE PRINCIPES Principes geven enerzijds richting en anderzijds bieden zij ruimte voor eigen invulling. De richting is nodig om een organisatie in beweging te krijgen en ruimte doet recht aan de Versie :

29 professionaliteit en verantwoordelijkheid van medewerkers om te bepalen hoe zij daar komen. Wij kiezen er bewust voor om vijf principes te hanteren, vanuit het idee dat ze eenvoudig te onthouden zijn en op één hand te tellen. Vier van de vijf principes die wij voorstellen zijn in feite een variant op de PDCA-cyclus van Deming, de principes: Samenwerken Dit principe is zowel belangrijk tussen vraag- en aanbodzijde (Business IT alignment) als tussen de verschillende IT-specialisten, applicatief en infrastructureel. De samenwerking is met name van belang om kennis te delen ten behoeve van het (tussen)resultaat. De robuustheid van betrouwbaarheid van een applicatie wordt onder andere gerealiseerd door security in depth te hanteren. Dit vraag om samenwerking in de keten zodat maatregelen op elkaar zijn afgestemd en elkaar aanvullen. Voor business en IT is het van belang dat er een optimale aansluiting is tussen bedrijfsproces en applicatie. Dit geldt zowel voor de ontwerp- als onderhoudsfase. Voor de vraagzijde is het van belang dat de applicatie een positieve bijdrage levert aan het bedrijfsproces. Voor de aanbodzijde is het van belang dat er een tevreden klant is en daarmee IT-bedrijfscontinuïteit. Samenwerking betekent dat partijen op elkaar zijn afgestemd. Er zal business kennis moeten zijn bij de IT-leverancier(aanbodzijde) en enige IT-kennis bij de business(vraagzijde) Wanneer deze samenwerking er onvoldoende is zullen vragen en opdrachten niet optimaal beantwoord kunnen worden en er zal over en weer onbegrip ontstaan. Doel bepaald de richting Wanneer men geen doel heeft dan is elke richting goed. In een organisatie waar veel mensen werkzaam zijn in verschillende units en teams, is het van belang om duidelijkheid te hebben Versie :

30 over het gewenste doel. Dit vergroot de efficiëntie en effectiviteit enorm. Wanneer het doel en daarmee de richting ontbreekt zullen medewerkers deze zelf gaan bepalen op basis van hun beeld van wat goed is voor de organisatie of klant. Wanneer vraag- en aanbodzijde samenwerken, kunnen zij gezamenlijk het doel bepalen. Hiermee wordt het een gemeenschappelijk doel gecreëerd. Dit legt de basis voor gemeenschappelijk commitment om het doel ook te willen realiseren. Maatregelen baseren op risico s (risicobeheersing) Alleen wanneer het doel bepaald is, kan onderzocht worden welke risico s er bestaan bij het realiseren van dat doel. Om tot effectieve maatregelen te kunnen komen dienen risico s actueel inzichtelijk te zijn. Een deel van de risico s zal stabiel zijn over een langere periode, terwijl een ander deel veel dynamischer is. Dit kunnen zowel risico s vanuit de business als de IT zijn. Door risico s in kaart te brengen en te onderhouden maakt een organisatie de stap van onbewust risico lopen naar bewust risico nemen. Risicoacceptatie door het verantwoordelijk management is daarin de volgende stap. IT-risico s zijn uiteindelijk ook businessrisico s. Daarom is samenwerking en afstemming tussen vraag- en aanbodzijde (business IT alignment) van belang om te komen tot een optimaal gemeenschappelijk beeld van de risico s, waarbij beide partijen vanuit verantwoordelijkheid en professie een aandeel leveren. Alleen voor risico s die niet geaccepteerd worden dienen maatregelen te worden genomen. Risico s dienen voor vraag- en aanbodzijde bekend te zijn vanuit verschillende invalshoeken, intern, extern, zwakheden en bedreigingen. Op deze manier ontstaat er een risico register, dat als basis dient om maatregelen te treffen. Vanuit het risico register zal een baseline, een specifieke set of een combinatie van maatregelen opgesteld worden. Meten en sturen op (tussen)resultaat Prof. C. Verhoef gaf aan dat er een audit regime nodig is om het realiseren van betrouwbare source code te ondersteunen, vaststellen dat maatregelen genomen zijn. Dit is een vorm van Versie :

31 meten van (tussen)resultaten. Omdat het doel en de te nemen maatregelen bekend zijn kan bepaald worden of en hoe er gestuurd moet worden. In het gehele traject van applicatie ontwikkeling en onderhoud zou men dit principe moeten hanteren, van functioneel ontwerp (incl. PvE) tot en met productie (monitoring/logging). Door dit principe te hanteren worden fouten in een zo vroeg mogelijk stadium ontdekt en de kans op Building Security In het grootst, met als eindresultaat een betrouwbare applicatie. Onderhoud dat wat betrouwbaar moet zijn Na acceptatie van de applicatie begint de productiefase, dit is de langste fase van de SDLC waarin een applicatie zich zal bevinden. Gedurende deze fase zullen er nieuwe bedreigingen en kwetsbaarheden ontstaan. Zowel de vraag- als aanbodzijde zullen zich hiervan bewust moeten zijn. Door het aspect betrouwbaarheid voldoende aandacht te blijven geven tijdens de productiefase, voorkomt men achterstallig onderhoud en blijft de applicatie betrouwbaar. Hiervoor is het nodig dat kwetsbaarheden en bedreigingen vanuit de verschillende domeinen actueel bijgehouden worden in het risico register, om tijdig wijzigingsvoorstellen in te kunnen dienen. Dit principe is bijvoorbeeld ook van toepassing op de kennis en kunde van het personeel, zij bepalen uiteindelijk de kwaliteit door de juiste maatregelen in het proces ten behoeve van het product te nemen. 4.2 VOORGESTELDE MAATREGELEN Vanuit de literatuur en met de principes in het achterhoofd hebben wij een stelsel van maatregelen opgesteld voor de SDLC, die in de case study getoetst zal worden. De maatregelen om de betrouwbaarheid te beheersen worden, om een overzichtelijk en gestructureerd geheel te krijgen, gegroepeerd naar de verschillende processtappen in ASL. Wie een maatregel moet uitvoeren is afhankelijk van hoe een SDLC binnen een organisatie is georganiseerd. In onderstaand figuur 1 is schematisch aangegeven waar de aandacht zich op richt in het ASL traject. De maatregelen in de eerste twee fasen richten zich vooral op de risico s. Eerst inzicht krijgen in de risico s en vervolgens eisen in het functioneel ontwerp stellen om deze risico s te verkleinen. De volgende twee fasen richten maatregelen zich op het realiseren van betrouwbaarheid en het toetsen hierop. Nadat de acceptatie door de verschillende partijen (klant, applicatiebeheer en hosting) is afgerond, kan de applicatie in productie en zullen er weer nieuwe risico s ontstaan. De feitelijke overgang van acceptatie naar productie dient gecontroleerd te Versie :

32 gebeuren via de verbindende processen. De maatregelen die daar genomen dienen te worden vormen in feite een aanvulling op de general IT-controls. FIGUUR 1 De risico s uit de productiefase vormen weer input voor de impactanalyse, waarmee de SDLC rond is. Maatregelen uit het sturende proces kwaliteit moeten dit proces op verschillende punten ondersteunen en aanvullen. Onderhoud en vernieuwing Maatregelen binnen de impactanalyse: Voer een business impact analyse uit voor het gebruik van de nieuwe applicatie, waarbij indien nodig ook een analyse wordt gemaakt met betrekking tot nieuwe technologie; Voer een risicoanalyse uit op zowel de ontwerp- als onderhoudsfase en betrek hierbij de gebruikte infrastructuur; Bepaal uit bovenstaande analyses welke betrouwbaarheidseisen (PvE) gesteld moeten worden, hanteer hierbij een classificatie Hoog/Midden/Laag; Actualiseer het risico register niet alleen voor de ontwerpfase maar zeker ook voor de productiefase (onderhoud). Hiervoor is monitoring en logging nodig in de productiefase, bijvoorbeeld Intrusion Detection en Prevention; Maatregelen in het ontwerpproces De vraag- en aanbodzijde stellen gezamenlijk het FO op; Betrouwbaarheidseisen uit het PvE worden in het FO onderverdeeld naar: Versie :