Betrouwbare applicaties realiseren - vurore.nl · 2 DOEL, SCOPE EN AANPAK VAN ... Daarom zijn wij...
Transcript of Betrouwbare applicaties realiseren - vurore.nl · 2 DOEL, SCOPE EN AANPAK VAN ... Daarom zijn wij...
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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. 1904639
Arnoud Goudbeek, nr. 1904787
Apeldoorn
Voorjaar 2011
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 3 -
INHOUDSOPGAVE
1 AANLEIDING.............................................................................................................................................. 4
2 DOEL, SCOPE EN AANPAK VAN HET ONDERZOEK....................................................................... 6
2.1 DOELSTELLING....................................................................................................................................... 6
2.2 SCOPE VAN HET ONDERZOEK.................................................................................................................. 7
2.3 AANPAK ................................................................................................................................................. 8
3 VOORONDERZOEK GERICHT OP HET ONTWIKKELEN EN ONDERHOUDEN VAN
BETROUWBARE APPLICATIES................................................................................................................... 10
3.1 BETROUWBAARHEID VAN EEN SOFTWAREPRODUCT ............................................................................. 10
3.2 DE SOFTWARE DEVELOPMENT LIFE CYCLE. ........................................................................................ 13
3.3 ONDERZOEK NAAR MAATREGELEN....................................................................................................... 22
4 CONCEPTUEEL ONDERZOEKSMODEL ........................................................................................... 28
4.1 GEHANTEERDE PRINCIPES .................................................................................................................... 28
4.2 VOORGESTELDE MAATREGELEN........................................................................................................... 31
5 UITWERKING CASE STUDY................................................................................................................. 36
5.1 INLEIDING ............................................................................................................................................ 36
5.2 BEVINDINGEN ONDERHOUD EN VERNIEUWING..................................................................................... 36
5.3 BEVINDINGEN VERBINDENDE PROCESSEN............................................................................................ 39
5.4 BEVINDINGEN KWALITEITSMANAGEMENT ........................................................................................... 40
5.5 ANALYSE.............................................................................................................................................. 41
5.6 CONCLUSIE........................................................................................................................................... 42
5.7 AANBEVELINGEN ................................................................................................................................. 42
6 ONDERZOEKSVRAGEN EN BEANTWOORDING............................................................................ 44
7 NAWOORD ................................................................................................................................................ 46
8 BRONNEN.................................................................................................................................................. 47
9 BIJLAGEN ................................................................................................................................................. 49
9.1 DEFINITIES EN SYNONIEMEN ISO 9126 ................................................................................................ 49
9.2 BESCHRIJVING OWASP PRINCIPES ...................................................................................................... 54
9.3 BESCHRIJVING BEVEILIGINGSPRINCIPES D. ROOK ................................................................................ 55
9.4 SANS TOP 25 SOFTWARE FOUTEN ........................................................................................................ 57
9.5 OWASP TOP 10 RISICO’S ..................................................................................................................... 59
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 marktonderzoek1 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 3 2009)
“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 29-10-2010)
De door SANS2 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 www.SANS.org en www.OWASP.org
2 SANS = SysAdmin Audit, Network, Security
3 OWASP = Open Web Application Security Program 4 http://www.cs.vu.nl/~x/knipselkrant/ag-93.html
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 6 -
2 DOEL, SCOPE EN AANPAK VAN HET ONDERZOEK
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 IT-
auditors 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.
2.1 DOELSTELLING
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
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.
2.2 SCOPE VAN HET ONDERZOEK
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
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.
SANS5 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 www.sans.org
2.3 AANPAK
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 ASL-
framework. Als laatste wordt gekeken naar risico’s die zich in het proces kunnen voordoen dit
in relatie tot het gewenst doel, productkwaliteit.
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.
3.1 BETROUWBAARHEID VAN EEN SOFTWAREPRODUCT
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Kenmerk6 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 13 -
Kenmerk6 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
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 (ASL7) 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 978-90-8753-312-0)
3.2 DE SOFTWARE DEVELOPMENT LIFE CYCLE.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 14 -
In bovenstaande figuur zien we dat het ASL-framework is onderverdeeld in drie lagen. OCM8
en ACM9 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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
register10
, 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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/business-
functionaliteit. 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
onderzoek11
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 www.SANS.org
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 DMZ12
) 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 CAB13
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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 CAB14
;
- 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 (OTAP15
) 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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-9126. 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 OTAP-
omgeving 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 22 -
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
3.3 ONDERZOEK NAAR MAATREGELEN
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 principes16
.
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 9.2.
16 http://www.owasp.org/index.php/Category:Principle
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 leiden17
. 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 9031313807)
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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. Voorbeelden18
hiervan worden met enige
regelmaat gepubliceerd op www.security.nl., 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.
18 http://www.security.nl/artikel/36456/1/Macbook_binnen_5_seconden_gehackt.html
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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 ontwikkel-
en onderhoudsproces uitgroeien richting een Secure-SDLC. Dit begrip komt men steeds vaker
tegen in literatuur19
waarmee aangegeven wordt dat er maatregelen genomen zijn ten behoeve
van het realiseren en onderhouden van betrouwbare applicaties.
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
19 http://www.securityinnovation.com/pdf/collateral/sdlc-compliance.pdf
http://www.prlog.org/11423160-wck-lancelot-ssdlc-security-system-development-lifecycle-offers-support-to-the-sdlc-process.html
4.1 GEHANTEERDE PRINCIPES
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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.
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
4.2 VOORGESTELDE MAATREGELEN
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 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:
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 33 -
o Functioneel, gericht op application controls;
o Product kwaliteit, gericht op ISO 9126;
o Beheer en onderhoud, gericht op ASL (ITIL voor infrastructuur);
� Indien er een baseline is die gehanteerd moet worden, dient deze in het FO expliciet
benoemd te worden;
� Vraag- en/of aanbodzijde zal een FO niet goed keuren als het aspect betrouwbaarheid
niet voldoende is uitgewerkt in het FO, middels maatregelen ter compensatie van de
risico’s volgens het risico register.
Maatregelen realisatieproces
� Hanteer de beveiligingsprincipes van OWASP en de ontwerpprincipes van Rook en
concretiseer deze in het ontwerp;
� In het TO wordt beschreven hoe de betrouwbaarheidseisen in samenhang tussen de
applicatie en infrastructuur worden gerealiseerd;
� Beoordeel het ontwerp op maatregelen ter compensatie van de risico’s volgens het
risico register;
� Pas secure programming toe op basis van MTHV’s (zie ook maatregel MTHV’s);
� Beoordeel of maatregelen volgens MTHV’s voldoende zijn om de risico’s af te dekken;
� Toets code op secure programming.
Maatregelen in het testproces
� Stel testplan op, gebaseerd op productrisicoanalyse (risico register) ten aanzien van
betrouwbaarheid;
� Voer betrouwbaarheidstesten uit gericht op realisatie, TO en FO;
� Test op misbruik middels test sets van abuse-cases en hanteer deze ook bij
regressietesten;
� Zorg ervoor dat de testomgeving gelijk is aan de productieomgeving;
� Bepaal of Attack & Penetration Testing nodig is.
Maatregelen bij implementatie.
� Aanbodzijde ondersteunt de vraagzijde bij de uitvoering van acceptatietesten
gerelateerd aan betrouwbaarheidseisen volgens PvE;
� Aanbodzijde ondersteunt de beheer- en exploitatieorganisatie bij de uitvoering van
acceptatietesten gerelateerd aan betrouwbaarheidseisen volgens het PvE.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 34 -
Verbindende processen
Maatregelen in het proces wijzigen
� Een wijzigingsverzoek moet voorzien zijn van een impact/risico classificatie ten
aanzien van betrouwbaarheid (samenwerking met het proces impactanalyse);
� Wijzigingen met impact/risico op betrouwbaarheid worden beoordeeld en geautoriseerd
door de change advisory board (CAB);
� Alleen geautoriseerde wijzigingen worden geaccepteerd;
� Zorg voor een roll-back scenario.
Maatregelen in het proces programmabeheer en distributie
� Definieer en onderhoud een definitieve software bibliotheek specifiek voor de
verschillende OTAP20
-omgevingen;
� Zorg voor een strikte scheiding van de OTAP omgevingen;
� Distributie wordt alleen uitgevoerd indien een roll-back beschikbaar is.
kwaliteitsmanagement
Organisatie gerichte maatregelen
� Het management draagt visie en strategie uit, tevens benoemt zij doelstellingen en
verantwoordelijkheden ten aanzien van betrouwbaarheid van applicaties;
� Betrouwbaarheidsdoelstellingen zijn opgenomen in de management PDCA21
-cyclus;
� Medewerkers worden opgeleid zowel ten aanzien van (security) awareness als vak
inhoudelijk, gedifferentieerd naar functie;
� Medewerkers worden opgeleid zowel ten aanzien van het uit te voeren proces als de te
hanteren MTHV’s;
� Binnen de organisatie is een expert team software security, zij hebben een adviserende,
controlerende en beoordelende taak in het voortbrengingsproces;
� Autorisaties dienen afgestemd te zijn op functies en rollen in de OTAP22
-omgevingen.
20 OTAP = Ontwikkel, Test, Acceptatie en Productie
21 PDCA = Plan Do Check Act.
22 OTAP = Ontwikkel, Test, Acceptatie en Ontwikkel.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 35 -
Product gerichte maatregelen
� Definieer per technologieplatform specifieke aspecten met betrekking tot
betrouwbaarheid;
� Zorg voor een actueel inzicht in risico’s (zwakheden en bedreigingen) per platform, dit
kan op basis van eigen risicoanalyses en/of productinformatie uit de markt;
� Realiseer standaard oplossingen onder andere voor:
o Identificatie, Authenticatie en Autorisatie;
o Key management;
o Rol management;
o Logging;
� Definieer de te gebruiken frameworks en libraries per technologie.
Maatregelen t.b.v. MTHV’s
� Er dienen gescheiden omgevingen voor OTAP te zijn ingericht;
� Stel vanuit architectuur ontwerpprincipes op en vertaal deze naar MTHV’s;
� Stel vanuit architectuur beveiligingsprincipes op en vertaal deze naar MTHV’s;
� Oplossingen voor bekende software fouten23
zijn verwerkt in MTHV’s (secure
programming);
� Oplossingen voor bekende risico’s24
zijn verwerkt in MTHV’s (secure programming).
Proces gerichte maatregelen
� Beschrijf en onderhoudt het proces van betrouwbare software ontwikkeling;
� Bepaal beoordelingsmethode voor de verschillende procesresultaten en maak dit
meetbaar;
� Overdrachtsmomenten moeten helder zijn met betrekking tot input, output en
kwaliteitseisen;
� Per proces is duidelijk welke MTHV’s gehanteerd dienen te worden en hierop wordt
gestuurd;
� De ASL- en ITIL-processen change- en configurationmanagement zijn op elkaar
afgestemd;
� Audit de SDLC op het realiseren van betrouwbaarheid;
� Zorg voor adequate functiescheidingen in het proces;
� Zorg voor duidelijkheid in rollen en verantwoordelijkheden.
23 Zie bijlage 9.4 : Top 25 software fouten SANS
24 Zie bijlage 9.5 : Top 10 risico’s OWASP
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 36 -
5 UITWERKING CASE STUDY
Nadat het conceptueel model is opgesteld is het in de case study voorgelegd aan betrokken
partijen binnen een grote software ontwikkelorganisatie. De belangrijkste vraag die naar
aanleiding van de gesprekken beantwoord moest worden is de derde en laatste deelvraag van dit
onderzoek, namelijk:
Zijn de voorgestelde maatregelen toepasbaar in de praktijk en wat zijn
de bevindingen?
Voor de toetsing van de maatregelen aan de praktijk zijn interviews gevoerd met het
verantwoordelijk management, architecten, ontwerpers, bouwers, testers, kwaliteitsadviseurs en
een IT auditor. De geïnterviewden werken in verschillende teams, aan verschillende applicaties
die gehost worden op verschillende technische platforms. Door deze brede doelgroep is het
review commentaar onafhankelijk geworden van programmeer- en hostingomgeving. Met
betrokkenen is gesproken over de scope, inhoud en diepgang en over ervaringen vanuit hun
functie.
De aanwezige kennis omtrent de problematiek van softwarekwaliteit was verschillend per
persoon. Afhankelijk van de aanwezige kennis is er een toelichting gegeven over het aspect
betrouwbaarheid van applicaties. Voor zover nodig hebben wij de maatregelen toegelicht vanuit
de gehanteerde principes.
In dit hoofdstuk worden eerst de bevindingen per proces besproken. Vervolgens komen we via
een analyse tot een conclusie.
Impact analyse
Men herkent het nut en de noodzaak van het uitvoeren van impactanalyse, zelf heeft men
ervaring met Technische Impact Analyse (TIA) en Functionele Impact Analyse (FIA) Het
expliciet meenemen van betrouwbaarheid en de impact/risico’s daarop is minder gebruikelijk,
men verwijst alleen naar een baseline. Impact richt zich vooral op de inspanning die gepleegd
5.1 INLEIDING
5.2 BEVINDINGEN ONDERHOUD EN VERNIEUWING
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 37 -
moet worden als gevolg van een wijziging. Recentelijk werd een impactanalyse op applicaties
uitgevoerd i.v.m. het doorvoeren van hardening, ten behoeve van betrouwbaarheid, van het
Unix-platform.
De volgende uitdagingen worden bij de impact analyse onderkend:
a) Samenhang der delen
De impact analyse kent een brede scope zowel binnen de vraag- als aanbodzijde,
bijvoorbeeld het applicatieve deel, de betrokken infrastructuur, functionaliteit versus
betrouwbaarheidseisen, relatie met andere wijzigingen. Het blijkt lastig te zijn om
samenhang aan te brengen tussen de analyses.
b) Complexiteit
Omdat er bijna nooit sprake is van een volledig nieuwe situatie, loopt men aan tegen oude
legacy systemen waardoor complexiteit ontstaat door verwevenheid met andere applicaties
en met de onderliggende infrastructuur.
c) Actueel risico register
Gedurende de onderhoudsfase zullen er nieuwe zwakheden en bedreigingen kunnen
ontstaan. In samenwerking met (technisch)applicatiebeheer en infrastructuur dienen deze
risico’s pro-actief gedefinieerd en beoordeeld te worden. Hoe is in deze fase de rolverdeling
en opdrachtverstrekking. Mogelijk dat hierover ook afspraken gemaakt moeten worden in
een SLA25
.
Ontwerp
In de ontwerpfase wordt beperkt, in formele zin, aandacht besteed aan betrouwbaarheidseisen.
De voorgestelde maatregelen met betrekking tot de betrouwbaarheid worden vanuit de eigen
praktijk herkend en als noodzakelijk beschouwd.
In de onderzochte praktijk wordt namelijk verwezen naar, zij het verouderde, kaders26
die op
onderdelen aansluiten bij de voorgestelde maatregelen. Deze kaders worden door beide partijen
beschouwd als baseline. Echter wanneer men doorvraagt naar de inhoud van de kaders dan
blijkt zowel bij de vraag- als aanbodzijde de scope, inhoud en doel onvoldoende bekend of
duidelijk te zijn. Er vindt in de regel geen applicatie specifieke afweging plaats vanuit een
impact/risico-analyse met betrekking tot betrouwbaarheidseisen. Door het hanteren van het
kader als baseline ziet de vraagzijde geen noodzaak tot een risico/impact-analyse of expliciete
goedkeuring van het FO ten aanzien van betrouwbaarheidseisen.
25 SLA : Service Level Agreement (ITIL)
26 VBA en VBI, voor application en general IT controls
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 38 -
Realisatie
De maatregelen genoemd in de realisatiefase roepen bij menigeen vragen op, dit als gevolg van
het feit dat kennis omtrent beveiliging- en ontwerpprincipes beperkt bekend is. We hebben
tijdens de gesprekken verduidelijkt dat het toepassen van deze principes een groot deel van de
bekende softwarefouten kan helpen voorkomen. Na deze uitleg was men het er mee eens dat dit
een toegevoegde waarde heeft voor het technisch ontwerp.
Ook het punt van secure programming was voor geïnterviewden een vrij onbekend terrein. Na
bestudering van beschikbare documentatie over MTHV’s blijken sommige aspecten overigens
wel geraakt te worden, bijvoorbeeld cross site scripting. Dit bevestigde de voorgestelde
maatregelen en de aandacht voor maatregelen uit kwaliteitsmanagement.
Afhankelijk van betreffende applicatie in het totale applicatielandschap is de afstemming met de
infrastructuur van meer of minder belang. De voorgestelde maatregelen werden wel als
belangrijk ervaren maar niet altijd van toepassing. Discussie was er over het OWASP principe
“vertrouw de infrastructuur niet” omdat dit ervaren wordt als een negatieve insteek. Dit geldt
zeker in de situatie waarbij juist nauw samengewerkt wordt met de unit Infrastructuur om te
komen tot een goede invulling van “Apply defense in depth ”, een ander OWASP principe.
Het onderzoek gaat er vanuit dat programmeurs zelf software schrijven. De praktijk leert dat
tooling steeds meer zijn intrede doet ook in het genereren van code. Voorbeeld hiervan is de
Google Web Toolkit voor het genereren van JavaScript. Afhankelijk van het gebruik van deze
tools kwam dit punt meer of minder ter sprake. Naast tooling wordt ook het internet steeds meer
gebruikt om delen van code te downloaden. Maatregelen in relatie tot deze beide aspecten
worden gemist door programmeurs die gebruik maken van dit soort mogelijkheden.
Men is bekend, vanuit onderhoudbaarheid, met het toetsen van code zowel door collegae als
door externe partijen. Ook betrouwbaarheid wordt met enige regelmaat door externe partijen
beoordeeld.
Uit de gesprekken bleek tevens dat het bestaande kader van een dermate abstract niveau is en
onvoldoende geoperationaliseerd is naar MTHV’s, waardoor het niet als effectief hulpmiddel
gezien wordt om de betrouwbaarheid te verhogen. Het roept meer vragen op dan dat het
oplossingen biedt.
Testen
In het testproces wordt gebruik gemaakt van de test methodiek Tmap. Daardoor werd de eerste
maatregel direct herkend. Voorwaarde is wel dat in de productrisicoanalyse ook het
kwaliteitsaspect betrouwbaarheid expliciet wordt meegenomen. Dit geldt ook voor de andere
fasen in het SDLC waar testers bij betrokken zijn. Testen op misbruik blijkt bij de gemiddelde
tester, testcoördinator of testplan niet in de scope te vallen.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 39 -
In de praktijk blijkt dat er bij een redelijk aantal webapplicaties wel, na advies van betrokken
specialisten, door het management besloten is om A&P-testen uit te laten voeren door externe
partijen. Deze praktijk bevestigt de toepasbaarheid van de voorgestelde maatregelen. Punt van
aandacht is om testresultaten (A&P) te vertalen naar structurele verbeteringen ten behoeve van
betrouwbaarheid. Kennis delen is hierbij van groot belang.
Implementatie
Bij implementatie blijken tijd, functionaliteit en performance de kritische acceptatiecriteria voor
de vraagzijde te zijn. Dit in combinatie met het feit dat men er vanuit gaat dat de applicatie
voldoet aan de baseline, wordt er door de vraagzijde geen expliciete acceptatietest uitgevoerd
gericht op betrouwbaarheid. Daarbij kwam de vraag aan de orde of de aanbodzijde niet zou
moeten aantonen dat het product voldoet aan de specificaties en eisen.
Wijzigingenbeheer
De maatregelen gericht op classificeren en autoriseren worden als zeer relevant beschouwd.
Hierover was feitelijk weinig discussie. Aandachtspunt blijft de eisen die gesteld worden.
Er ontstond discussie over de autorisaties van specialisten. Enerzijds hebben programmeurs
hoge rechten in de OTA-omgeving27
voor hun ontwikkelwerk en anderzijds zijn dezelfde
specialisten soms nodig om incidenten op te lossen in de P-omgeving waarbij het risico bestaat
dat programmeurs met hoge rechten in productie ongeautoriseerde wijzigingen kunnen
uitvoeren.
Ook bij het gebruik van queries in combinatie met hoge rechten loopt men het risico dat er
ongeautoriseerd wijzigingen kunnen worden doorgevoerd. Kortom, belangrijke succesfactor bij
dit proces zijn de juiste autorisaties op het juiste moment. Dit punt sluit aan bij de maatregel
hierover binnen kwaliteitsmanagement.
Programmabeheer en distributie
Dit zijn voor betrokkenen vanuit ITIL herkenbare maatregelen. Ervaring in een grote organisatie
met veel software (deel)producten leert dat het soms op de details aankomt die in de
verschillende OTAP-omgevingen snel kunnen veranderen. Dat maakt het soms lastig om zaken
op dat niveau actueel te houden.
27 OTAP = Ontwikkel, Test, Acceptatie en Productie omgeving
5.3 BEVINDINGEN VERBINDENDE PROCESSEN
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 40 -
Algemene opmerking bij de maatregelen binnen kwaliteitsmanagement was dat gestreefd zou
moeten worden naar integratie en samenhang met bestaande processen binnen de organisatie.
Als voorbeeld hiervan de maatregelen met betrekking tot opleiding, dit hoort van nature binnen
de HRM-processen.
Organisatie
De genoemde maatregelen komen in grote mate overeen met wat de organisatie nu doet ten
aanzien van een ander ISO 9126 kwaliteitskenmerk namelijk Onderhoudbaarheid.
Het is goed om te zien dat men nut en noodzaak onderkent van de maatregelen uit eigen
praktijk. Echter managers geven aan dat zij gericht zijn op KPI’s waarop zij worden beoordeeld,
wel onderhoudbaarheid maar niet de betrouwbaarheid. Het ontbreekt de medewerkers vaak aan
bewustzijn van de risico’s en kennis hoe zij betrouwbaarheid kunnen realiseren.
Product en Standaarden (MTHV)
De maatregelen gericht op het product en MTHV’s kennen een grote mate van verwevenheid.
Men herkent op hoofdlijn de maatregelen vanuit de aandacht voor onderhoudbaarheid. Toch
onderkent men hier een aantal uitdagingen namelijk:
a.) Dynamiek
Met name zwakheden en bedreigingen kunnen op korte termijn veranderen en hoe wordt dan
gezorgd dat MTHV’s actueel blijven en bestaande applicaties worden aangepast;
b.) Meetbaarheid
Het management wil graag kunnen meten, daar zijn meetbare criteria voor nodig, welke zouden
dat voor betrouwbaarheid zijn en zijn er tools omdat efficiënt en betrouwbaar(!) te meten?
c) Validiteit
Er moet door het management duidelijk worden aangegeven welke MTHV’s moeten worden
gebruikt. Er is namelijk een wildgroei aan MTHV’s ontstaan. Hierbij komt het voor dat
meerdere MTHV’s voor één onderwerp beschikbaar zijn zonder dat de gebruiker weet welke
juist is, danwel wat de verschillen zijn tussen de MTHV’s.
Proces
Uit de gesprekken blijkt dat er op verschillende manieren aangekeken wordt tegen processen en
procesdenken. Waar men het over eens is, is dat het proces geen doel op zich moet zijn, focus
moet gericht zijn op de gewenste (tussen)productkwaliteit. Hiervoor heeft men in de
onderzochte praktijk een beoordelingslijn van Uitvoeren Beoordelen Goedkeuren Informeren
5.4 BEVINDINGEN KWALITEITSMANAGEMENT
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 41 -
(UBGI) Vanuit dit gegeven worden een aantal maatregelen weer erkend en herkend vanuit de
aandacht voor onderhoudbaarheid.
De audit maatregel voor SDLC werd ten tijde van het onderzoek ruim 1,5 jaar niet meer gedaan
omdat de focus bij deze audits, naar het inzicht van het management, te veel proces in plaats van
product georiënteerd was. Toch is dit wel een signaal dat de voorgestelde maatregel toepasbaar
is, alleen dient de focus/opdracht van een audit goed te zijn afgestemd met het management.
Uit de interviews blijkt dat een groot deel van de voorgestelde maatregelen worden herkend. De
herkenning en erkenning van maatregelen komt voor een belangrijk deel voort uit de ervaring
met het realiseren van het ISO 9126 kwaliteitskenmerk Onderhoudbaarheid.
Reden waarom een groot aantal maatregelen toch niet getroffen worden is gelegen in;
a.) De vraagzijde is vooral gefocused op functionaliteit en performance en gaat er impliciet
vanuit dat de risico’s ten aanzien van betrouwbaarheid zijn afgedekt middels een verouderd
kader. In lijn hiermee is acceptatie gericht op functionaliteit en performance;
b.) De aanbodzijde stuurt op kritische performance indicatoren, echter de betrouwbaarheid van
applicaties maakt daar geen expliciet onderdeel vanuit. Niet geïnitieerd vanuit de vraagzijde
maar ook niet vanuit eigen professionaliteit gebaseerd op visie en strategie.
Uit de resultaten van de gesprekken blijkt uiteindelijk dat het uitvoeringsniveau van de
voorgestelde maatregelen voor het belangrijkste deel bepaald wordt door bovenstaande twee
punten. Toch blijkt er dat op individueel niveau (managers en specialisten) goede initiatieven
worden genomen om applicaties betrouwbaar te maken. In CMM28
termen zit men dan tussen
het niveau initial en managed.
De betrouwbaarheid van een applicatie wordt mede bepaald door applicatieonderhoud en de
onderliggende infrastructuur. Deze domeinen dienen daarom vanaf het PvE in voldoende mate
te worden meegenomen. Autorisaties van specialisten vormen een potentieel risico voor de
betrouwbaarheid gedurende de gehele SDLC. Er zal hiervoor een evenwicht gevonden moeten
worden tussen werkbaarheid en beheersbaarheid. Bewustzijn en professionaliteit zijn dan
belangrijke randvoorwaarden, die onderhouden dienen te worden.
Wanneer de aanbod/vraag-organisatie een standaard kader hanteert voor betrouwbaarheidseisen,
dient men er zorg voor te dragen dat het kader actueel is en expliciet wordt gehanteerd. Voor de
aanbodorganisatie is het van groot belang dat een kader wordt geconcretiseerd in relevante
MTHV’s (juiste opzet), anders mist het zijn doel.
28 CMM = Capability Maturity Model
5.5 ANALYSE
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 42 -
Van een professionele aanbodzijde mag verwacht worden dat zij betrouwbaarheid weet te
realiseren door de juiste maatregelen te treffen in de verschillende processen. Hiervoor zijn
bewustwording, opleiding, training en management commitment van essentieel belang. De
vraagzijde moet hier ook bij betrokken worden.
Als betrouwbaarheid in het begin niet expliciet wordt geadresseerd zullen er gaandeweg het
ontwikkel- en onderhoudstraject diverse redenen zijn om er geen of onvoldoende aandacht aan
te besteden. Er wordt in feite op andere resultaten gestuurd.
De vraagzijde bepaald uiteindelijk het gewenste resultaat, echter gezien de complexiteit zullen
zij de aanbodzijde nodig hebben voor advies. Idealiter wordt dit concreet in het programma van
eisen en het functioneel ontwerp en dan ontstaat er de noodzakelijke business IT alignment.
De toepasbaarheid van de maatregelen zelf, wordt over het algemeen positief beoordeeld vanuit
de eigen praktijkervaring met het kwaliteitsaspect onderhoudbaarheid.
Het conceptueel model is herkenbaar voor de betrokkenen uit de praktijk. Zij vinden dat het
model vooral door de samenhang van de maatregelen toepasbaar is in de praktijk, maar geven
tegelijkertijd aan dat het moeilijk is deze samenhang structureel te realiseren en te onderhouden.
Zij vinden tevens dat betrouwbaarheid een basiswaarde moet zijn voor een ontwikkelorganisatie
en dat zij vanuit hun eigen ervaringen meer pro-actief moeten adviseren naar de vraagzijde.
Voor organisaties die ook de strategische ASL-processen uitvoeren ligt het voor de hand om
ook daar betrouwbaarheid als aandachtsgebied mee te nemen als onderdeel van software
kwaliteit.
Naar aanleiding van de case study doen wij de volgende aanbevelingen:
1.) Vraag- en aanbodzijde dienen een gemeenschappelijke visie, strategie en doel te bepalen ten
aanzien van betrouwbaarheid van applicaties en deze uit te dragen. Gebruik dit vervolgens
als input voor het SDLC traject;
2.) Leidt managers en specialisten op vanuit risico bewustwording naar vakmanschap. Gebruik
hierbij kennis uit de markt en borg deze kennis in het proces door standaardisatie en door
voldoende geoperationaliseerde MTHV’s;
5.6 CONCLUSIE
5.7 AANBEVELINGEN
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 43 -
3.) Bestuur het realiseren en onderhouden van betrouwbare applicatie middels een PDCA-
cyclus. Zorg ervoor dat zowel de vraagzijde als onderhoudspartijen hierbij voldoende
betrokken zijn;
4.) Hanteer het stelsel van maatregelen als kader ter ondersteuning aan het management voor de
inrichting van de SDLC.
Neem vervolgens bij de eerst volgende IT-audit het kwaliteitskenmerk betrouwbaarheid van
applicaties mee in de scope en beoordeel als eerste de opzet van bovengenoemde aanbevelingen.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 44 -
6 ONDERZOEKSVRAGEN EN BEANTWOORDING
Doel van het onderzoek is een bijdrage leveren aan het ontwikkelen en onderhouden van
betrouwbare applicaties. In dit hoofdstuk komen we terug op de gestelde onderzoeksvraag in dat
kader. Voordat we de centrale vraag beantwoorden kijken we eerst naar de deelvragen. De
eerste deel vraag luidt:
Waaruit bestaat de Software Development Life Cycle en welke risico’s
met betrekking tot betrouwbaarheid zijn daarin te onderkennen?
Vanuit de literatuur is gekeken uit welke processtappen een SDLC is opgebouwd. Dit hebben
we beantwoord door gebruik te maken van het Application Services Library framework. Binnen
ASL zijn strategische, tactische en operationele processen te onderkennen. De strategische
processen richten zich op organisatie- en applicatieontwikkelingen voor de lange termijn. De
tactische processen hebben voornamelijk een sturend karakter. Binnen de operationele laag is er
een verdeling tussen onderhoud /vernieuwing en beheer met daar tussen software change en
deployment. De operationele processen kennen op onderdelen een overeenkomst met processen
binnen ITIL. We hebben hierbij aangegeven welke risico’s bij het uitvoeren van deze
procestappen kunnen optreden.
Voordat de tweede deelvraag beantwoord kon worden is het begrip betrouwbaarheid
gedefinieerd vanuit de ISO-9126 norm voor softwarekwaliteit. De kenmerken vanuit de ISO-
norm 9126 die wij geselecteerd hebben voor het begrip betrouwbaarheid zijn volwassenheid,
foutbestendigheid, beschikbaarheid, degradeerbaarheid, herstelbaarheid, beveiligbaarheid,
juistheid, stabiliteit, testbaarheid, beheerbaarheid en wijzigbaarheid. Risico’s zijn vervolgens
beschreven ten aanzien van betrouwbaarheid en ASL, om vervolgens bij de tweede deelvraag
uit te komen.
Welke maatregelen dienen genomen te worden in de SDLC om de
betrouwbaarheid van applicaties te beheersen?
In de wetenschap dat medewerkers fouten maken zijn er maatregelen benoemd binnen de
processtappen van ASL. Voor de maatregelen hebben wij literatuur bestudeerd en principes
gehanteerd. Criteria ten aanzien van literatuur die wij stelden waren openheid, actualiteit en
validiteit. Op basis hiervan zijn wij uitgekomen bij modellen van SAMM en BSIMM, de
beveiligingsprincipes van OWASP, de ontwerpprincipes van David Rook. Tevens hebben we
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 45 -
het menselijk handelen beschouwd om aan te geven waarom de mens een bepalende factor is in
het geheel. De maatregelen die genomen moeten worden zijn in de volgende vier groepen onder
te verdelen namelijk:
� Afstemming tussen vraag- en aanbodzijde omtrent betrouwbaarheidseisen;
� Betrouwbaarheid bewust meenemen in ontwerp en realisatie;
� Testen en toetsen op het realiseren en onderhouden van betrouwbaarheid;
� Besturing vanuit doelstellingen en risico’s.
Vervolgens is het conceptueel model besproken met specialisten in de praktijk, om de derde
deelvraag te beantwoorden.
Zijn de voorgestelde maatregelen toepasbaar in de praktijk en wat zijn
de bevindingen?
De conclusie vanuit de case study is dat het model toepasbaar is, waarbij is aangegeven dat het
beheersen van de samenhang van de maatregelen een serieuze uitdaging is. Uit de praktijk blijkt
dat strategie en sturing door het verantwoordelijk management cruciaal is voor de effectiviteit in
het realiseren van betrouwbaarheid.
Tot slot de 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?
Om de betrouwbaarheid van applicaties te vergroten moet in de SDLC aandacht zijn voor:
� Business en IT alignment, vanuit actuele risico’s naar PvE en FO voor ontwikkeling en
onderhoud;
� Governance met betrekking tot strategie, doelstellingen en bewuste professionaliteit van
medewerkers om betrouwbaarheid te kunnen realiseren;
� Dat betrouwbaarheid vanaf het ontwerp wordt meegenomen vanuit principes en
standaarden, waarbij tevens oog is voor de onderliggende infrastructuur;
� Dat betrouwbaarheid wordt meegenomen in de beoordeling van realisatie en pro-actief
onderhoud.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 46 -
7 NAWOORD
Als IT-auditor hebben we niet altijd de beschikking over een kant en klaar normenkader dat
gebruikt kan worden tijdens een audit. Bij het ontbreken van een passen normenkader zal je er
zelf één moeten opstellen en afstemmen met de opdrachtgever. In feite was er binnen ons
onderzoek sprake van een vergelijkbare situatie. We hebben op basis van literatuur een
normenkader opgesteld en dit afgestemd met specialisten uit de praktijk.
Het definiëren van de scope bleek een serieus leerpunt vanwege de drang naar volledigheid. Net
als in de audit praktijk is de beschikbare tijd een belangrijke factor waar rekening mee gehouden
dient te worden. We hebben geleerd en soms geworsteld met het op een logische manier
afbakenen van het onderzoek. Dit leerpunt geldt in feite ook voor het punt van diepgang, tot
welk detail niveau ga je.
Het is een fase van uitwerken en weer wegstrepen. In deze fase hebben we ook ervaren dat het
een voordeel is wanneer IT-auditors met een verschillende achtergrond samenwerken, je houdt
elkaar en het onderzoek evenwichtiger.
Doordat we met veel verschillende specialisten in het vakgebied hebben gesproken kregen we
meer gevoel bij de praktijk en hoe je daar vanuit het audit vakgebied een bijdrage aan kan
leveren, zodat het onderzoek geen doel op zich is geworden.
Op het moment dat je met een onderzoek als dit bezig bent zit je hoofd vol met veel kennis
omtrent het onderwerp en bleek het een uitdaging te zijn om een en ander helder op papier te
krijgen. Het aanbrengen van structuur en het voorkomen van goed bedoelde herhalingen waren
leerpunten.
We hebben ervaren naar analogie van het plaatje op de titelpagina dat software ontwikkelen is
als een puzzel. De stukjes moeten allemaal op een juiste manier in elkaar vallen anders krijg je
geen goed, betrouwbaar en robuust geheel.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 47 -
8 BRONNEN
ISO 9126
Site : http://www.smartest.nl/verdieping/kwaliteitsmodellen/iso9126
ASL 2 Een framework voor applicatiemanagement
Schrijver : Remko van der Pols
Uitgever : van Haren publishing
ISBN : 9789087533120
Site : http://www.aslbislfoundation.org/
Whitepaper Raamwerk Beveiliging Webapplicaties
Auteur : GOVCERT
Versie : 2.0
Datum : 4 mei 2010
Site : www.govcert.nl
Building Security In Maturity Model
Auteurs : Gary McGraw, Ph.D.,Brian Chess, Ph.D., Sammy Migues
Versie : 2
Datum : mei 2010
Site : http://bsimm2.com/index.php
Software Assurance Maturity Model
Auteur : Pravir Chandra
Versie : 1.0
Site : http://www.opensamm.org/
Framework for Application and Data Security
Auteurs : R. Paans, J. Fasten, L. Benschop
Versie : 0.03
Datum : 4 juni 2011
Prof. Dr. C. Verhoef : http://www.cs.vu.nl/~x/knipselkrant/ag-93.html
The State of IT Auditing in 2007,
Auteur : Hinson, G.,
Uitgever : EDPACS,
Editie : volume 36, issue 1 July 2007, pages 13-31, 2007
D.Rook: http://www.beveiligingninja.co.uk
OWASP: http://www.owasp.org/index.php/Category:Principle
SANS: http://www.sans.org/top25-software-errors/
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 48 -
Kwaliteit van softwareproducten.
Auteurs : Bob van Zeist, Paul Hendriks, Robbert Paulussen, Jos Trienekens
Datum : 1996
Top 25 softwaremissers slaat in
Auteur : Thijs Doorenbosch
Publicatie : Automatiseringsgids, 3 2009
Universiteitssoftware blijkt langdurig lek
Auteur : Brenno de winter
Publicatie : Webwereld, 29-10-2010
Mark van Sommeren en Manfred Flohr in CHIP | november 2006
Integraal ontwikkelen van organisatie en informatiesystemen
Auteurs : Betz, B., Roelofs, J., Vrins, J.
Datum : 1995
Bateson&Dilts:
http://qualitybs.wordpress.com/2010/10/06/verandering-en-probleemoplossing-volgens-
bateson-en-dilts/
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 49 -
9 BIJLAGEN
Kenmerk Engels Definitie Synoniemen
en verwante
begrippen
FUNCTIONALITEIT functionality
Mate waarin het
informatiesysteem
functioneel correct is
Effectiviteit
Geschiktheid suitability Mate waarin de gewenste
functies aanwezig zijn en
geschikt om gespecificeerde
taken uit te voeren
Functionaliteit (in
enge zin),
Passendheid,
Volledigheid,
Compleetheid
Juistheid
accuracy Juistheid van de uitvoer van
het systeem, overeenkomstig
de invoer en de
gespecificeerde
bewerkingen.
Nauwkeurigheid,
Plausibiliteit,
Datakwaliteit
Koppelbaarheid interoperabilit
y
Gemak waarmee het systeem
gegevens kan uitwisselen
met andere systemen
Connectiviteit
Functionele
standaardisatie
compliance Mate waarin de
functionaliteit en de
gebruikersinterface zich
conformeren aan
standaarden die extern
worden opgelegd
(bedrijfsstandaarden,
wetgeving,
systeemgerelateerde
afspraken)
Standaardisatie,
Inschikkelijkheid
Beveiligbaarheid security Mate waarin opzettelijk of
abusievelijk ongeoorloofde
Beveiliging
9.1 DEFINITIES EN SYNONIEMEN ISO 9126
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 50 -
Kenmerk Engels Definitie Synoniemen
en verwante
begrippen
toegang wordt voorkomen
Traceerbaarheid traceability Mate waarin herkomst en
correcte verwerking van data
door het systeem op
verschillende momenten in
de verwerking gecontroleerd
kan worden
Herleidbaarheid,
Controleerbaarheid
Localiseerbaarheid niet in
extended ISO!
Gemak waarmee het systeem
op locale omstandigheden
(taal, karakterset, symbolen,
wetgeving) aangepast kan
worden.
Inrichtbaarheid
BETROUWBAARHEID reliability Mate waarin het systeem
blijft functioneren, ook
tijdens storingen
Volwassenheid maturity Mate waarin fouten en
kinderziektes verholpen zijn
en het systeem vrij blijft van
storingen
Bedrijfszekerheid,
Stabiliteit,
Stabiliteit bij
veranderingen
Beschikbaarheid availability Mate waarin het systeem op
de gewenste tijden
beschikbaar is voor de
gebruiker
Foutbestendigheid fault tolerance Mate waarin het systeem
bestendig is tegen bedoeld of
onbedoeld onjuist gebruik en
tegen fouten in aanpalende
systemen
Robuustheid,
Bestendigheid
Fouttolerantie
Degradeerbaarheid degradability Mate waarin de essentiële
functies van het systeem
blijven functioneren tijdens
en na storingen
Zelfherstellend
vermogen,
Veerkracht
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 51 -
Kenmerk Engels Definitie Synoniemen
en verwante
begrippen
Herstelbaarheid recoverability Gemak waarmee het systeem
na uitval weer operationeel
te maken is, zonder
gegevensverlies
BRUIKBAARHEID usability Mate waarin het systeem
geschikt is voor gebruik
Gebruikersvriendelijkheid user
friendliness
Mate waarin het product is
afgestemd op de kennis en
ervaring van gebruikers
Opm: dit is een
apart subkenmerk,
maar men kan
terecht opmerken
dat dit slechts een
resultante is van
andere
subkenmerken.
Overzichtelijkheid understand-
ability, clarity
Gemak waarmee de
gebruiker het concept en de
mogelijkheden van het
systeem kan overzien en
vinden
Begrijpelijkheid,
Begrijpbaarheid,
Duidelijkheid,
Toegankelijkheid
Leerbaarheid learnability Snelheid waarmee een
gebruiker de functies van het
systeem kan leren gebruiken
Bedienbaarheid operability Snelheid en gebruiksgemak
voor (ervaren) gebruikers
Werkbaarheid,
Gebruiksgemak,
Gebruikersgemak
Duidelijkheid explicitness Mate waarin het systeem
inzicht verschaft in de
verwerkingsstatus
(zandlopers, statusbar, …)
Inzichtelijkheid
Instelbaarheid customisabilit
y
Mate waarin het systeem kan
worden ingesteld op wensen
van de gebruiker of de
afdeling
(voorkeursinstellingen, etc.)
Configureerbaarhei
d, Flexibiliteit,
Aanpasbaarheid
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 52 -
Kenmerk Engels Definitie Synoniemen
en verwante
begrippen
Aantrekkelijkheid attractiveness Mate waarin het systeem
door uiterlijk, gedrag en
service, tegemoetkomt aan
vaak onuitgesproken
gebruikersverwachtingen,
ook voor esthetiek, mode,
etc.
Uitrustingsniveau,
Look en feel
Behulpzaamheid helpfulness Mate waarin helpfuncties
beschikbaar zijn
EFFICIENTIE Efficiency Mate waarin het systeem
met beschikbaar gestelde
middelen presteert
Tijdsbeslag time
behaviour
Responstijd,
transactiesnelheid, snelheid
batchverwerking
Performance,
Tijdgedrag
Responsiesnelheid
Middelenbeslag resource
behaviour
Hoeveelheid benodigde
resources (netwerkcapaciteit,
schijfruimte, geheugen; in-
en extern)
Zuinigheid
OVERZETBAARHEID Portability
Mate waarin het systeem
ook goed werkt op andere
hardware/platformen
Aanpasbaarheid adaptability Gemak waarmee het systeem
overgezet kan worden naar
een ander
hardware/software-platform
of naar een nieuwe versie
daarvan
Overdraagbaarheid
Installeerbaarheid installability Snelheid en gemak waarmee het
systeem ge(de)installeerd kan
worden
Technische
standaardisatie
conformance Mate waarin het systeem zich
houdt aan technische
standaarden en afspraken, mede
ten behoeve van de portabiliteit
Inschikkelijkheid,
Naleving
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 53 -
Kenmerk Engels Definitie Synoniemen
en verwante
begrippen
Inpasbaarheid replaceability a. Het gemak waarmee het
systeem een bestaand systeem
kan vervangen
b. Mate waarin het systeem
aansluit bij de
bedrijfsprocessen en
(handmatige) procedures
Vervangbaarheid
ONDERHOUD-
BAARHEID
Maintainability Maat voor het gemak waarmee
het systeem onderhouden kan
worden
Analyseerbaarheid analysability Gemak waarmee de oorzaak van
fouten opgespoord kan worden
en waarmee te wijzigen
onderdelen kunnen worden
gevonden
Fouttraceerbaarheid
Wijzigbaarheid changeability Gemak waarmee het systeem
gecorrigeerd, gewijzigd en
verbeterd kan worden.
Corrigeerbaarheid,
Veranderbaarheid
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
Herbruikbaarheid reusability Mate waarin (delen van) het
systeem herbruikbaar zijn in
andere systemen
Schaalbaarheid niet in extended
ISO! Gemak waarmee het systeem
uitgebreid kan worden bij een
toenemend aantal gebruikers en
behoefte aan meer snelheid,
verwerkings- en opslagcapaciteit
Scalability,
Uitbreidbaarheid,
Extensibility
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 54 -
Apply defense in depth (zorg voor een gelaagde verdediging);
Dit principe geeft aan dat het gebruik van gelaagde beveiligingsmechanismen het systeem als
geheel veiliger maakt. Als een mechanisme faalt, dan zijn er nog andere mechanismen over die
het systeem nog veilig genoeg kunnen houden.
Use a positive security model (gebruik whitelisting);
Dit principe geeft aan dat je definieert wat is toegestaan. Al het overige wordt niet geaccepteerd.
Fail securely (behandel fouten/foutmeldingen veilig);
Als er een fout optreedt zorg dan dat die beheerst behandeld wordt, zodat hier geen misbruik
van kan worden gemaakt.
Run with least privilige (hanteer initieel de laagste rechten);
Dit principe geeft aan de je aan een account de laagst mogelijke rechten moet toekennen
waarmee nog steeds de werkzaamheden van een functie kunnen worden uitgevoerd. In een
beheerst proces van autoriseren kunnen daarna de rechten eventueel worden uitgebreid.
Avoid security by obscurity (beveilig niet door zaken te verbergen);
Dit principe geeft aan dat het verbergen van informatie van het systeem of betreffende het
systeem niet veilig is. Als men hier specifiek op zoek naar is zal men de verborgen informatie
vrijwel zeker vinden.
Keep security simple (houdt beveiliging simpel);
Dit principe geeft aan dat je ontwerpen en software code niet onnodig complex moet maken
Detect intrusions (detecteer indringers);
Dit principe heeft drie elementen in zich te weten Het moet mogelijk zijn alle
beveiligingsgerelateerde gebeurtenissen te loggen, er moeten procedures zijn die ervoor zorgen
dat de logs dagelijks worden gemonitord en er moeten procedures zijn om juist te reageren op
indringing wanneer dit is geconstateerd.
Don’t trust infrastructure / Don’t trust services (vertrouw de infrastructuur en/of services niet);
Dit principe geeft aan dat het onwaarschijnlijk is dat u invloed kunt uitoefenen op het
beveiligingsgedrag van alle externe derden (klanten,leveranciers etc) Daarom is het van belang
9.2 BESCHRIJVING OWASP PRINCIPES
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 55 -
al deze partijen te behandelen alsof zij geen beveiligingsmaatregelen hebben getroffen, en dus
zelf maatregelen te treffen.
Establish secure defaults (zorg voor een veilige basis)
Als je een applicatie oplevert zorg er dan voor dat de default waarden in een applicatie al voor
een goede beveiliging zorgen, zoals bijvoorbeeld wachtwoord lengte en complexiteit en goede
inputvalidatie.
Invoer validatie (input validation)
Als je er voor zorgt dat alle data die wordt ontvangen en verwerkt afdoende wordt gevalideerd
kunnen kwetsbaarheden worden voorkomen. Hiertoe zijn er 2 mogelijkheden namelijk
whitelisting en blacklisting. Whitelisting is de mogelijkheid die de meeste zekerheid biedt. Er
wordt een set van goede waarden gedefinieerd die mogen voorkomen. Hierbij is het dus wel
zaak dat is bepaald door de business welke waarden dit moeten zijn. Als er een goede invoer
validatie plaatsvindt qua syntax en minimale en maximale lengte kunnen kwetsbaarheden als sql
injectie of cross site scripting worden voorkomen, tevens kan er geen informatie worden
verwerkt die buiten de grenzen die de business heeft bepaald liggen. Een voorbeeld van hiervan
is dat als bijvoorbeeld de prijs van een artikel moet worden ingevoerd en de prijzen liggen niet
boven de € 100, het dus niet mogelijk moet zijn om een hogere prijs in te voeren.
Uitvoer validatie (output validation)
In aanvulling op de validatie van het ontvangen van data zal er ook validatie moeten
plaatsvinden op de uitvoer van de data, waarbij wordt gevalideerd op syntax, lengte en codering.
Ook hier is whitelisting de aangewezen methode. Hiermee kan worden voorkomen dat er
onbedoelde of ongewenste inhoud in de uitvoer zit zoals bijvoorbeeld scriptingcode die een
aanvaller gebruikt in cross site scripting aanvallen, informatie over gebruikte technologieën op
de server en uitgebreide foutmeldingen.
Fout behandeling (error handling)
Vroeg of laat krijgt elke applicatie een keer te maken met een uitzondering, hierbij is het van
belang om de foutberichten die dit oplevert zo in te richten dat mogelijke misbruikers (soms de
veroorzaker van het foutbericht) hier geen vitale informatie betreffende het systeem of de
applicatie uit kunnen halen. Het foutbericht die de gebruiker te zien krijgt moet alleen algemene
informatie bevatten, zoals bijvoorbeeld server fout neem contact op met de helpdesk..
9.3 BESCHRIJVING BEVEILIGINGSPRINCIPES D. ROOK
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 56 -
Authenticatie (authentication)
Zorg ervoor dat er een sterke authenticatie procedure in de applicatie wordt ingebouwd.
Hiermee wordt voorkomen dat onbevoegden toegang krijgen tot de applicatie. Deze procedure
moet worden ondersteund door een goede wachtwoord procedure en een goede procedure van
uitgifte van gebruikersnamen. Hierbij is niet alleen de sterkte van het wachtwoord van belang
maar ook hoe het wachtwoord wordt opgeslagen. Daarnaast zal ook het geautomatiseerde
systeem dat functioneert bij het vergeten van het wachtwoord veilig moeten zijn.
Autorisatie (authorization)
De autorisatie moet samengaan met authenticatie. Hierbij zal het principe moeten worden
gehanteerd dat standaard de laagste rechten op de applicatie worden gegeven. Op basis van een
beheerste procedure voor het toekennen van autorisaties kan dit dan worden aangepast aan de
rol en functie van de gebruiker.
Sessie management (session management)
Als een gebruiker aanlogt bij een applicatie met zijn gebruikersnaam en wachtwoord wordt een
sessie id gegenereerd. Deze sessie id’s moeten minimaal even sterk zijn als de wachtwoorden
die worden gebruikt, deze sterkte kan verschillen per applicatie, afhankelijk van de gevoeligheid
van de data die de applicatie gebruikt. Ook de sessie id moet worden opgeslagen op een veilige
locatie, net zoals bij wachtwoorden. Om misbruik te voorkomen zal bij het uitvoeren van een
gevoelige transactie om hernieuwd aanloggen gevraagd worden, waardoor een nieuwe sessie id
wordt gegenereerd, ook moet de sessie na bepaalde tijd ongebruikt te zijn automatisch worden
afgesloten. Sessie id’s moeten beveiligd worden verzonden en een sessie moet altijd worden
afgesloten Dit moet er toe leiden dat onbevoegden geen toegang kunnen krijgen tot de sessie en
daarmee bijvoorbeeld een denial of service(DDOS) aanval kunnen doen.
Veilige communicatie (secure communication)
Zorg ervoor dat communicatie veilig verloopt. Dit lijkt een open deur, waar echter vaak
problemen door worden veroorzaakt is het feit dat niet direct bij de start van een sessie veilig
wordt gecommuniceerd en het feit dat niet de juiste versies van beveiligingsmechanismen
worden gebruikt. Als de start van de veilige communicatie dus op de juiste momenten gebeurt
met de juiste mechanismen voorkomt dit onderschepping van (gevoelige)data.
Veilige opslag (secure storage)
Zorg ervoor dat data is beveiligd, denk hierbij ook aan wachtwoorden en sessie details die
worden vastgelegd. Zorg ervoor dat dit gebeurd met een encryptiemethode die toereikend is.
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 57 -
Veilige toegang tot middelen (secure resource access)
Met authenticatie en autorisatie en een veilig sessie management is dit in principe geregeld,
echter je moet er wel zorg voor dragen dat je niet om deze procedures heen kunt.
Rank ID Name
[1] CWE-79 Improper Neutralization of Input During Web Page Generation
('Cross-site Scripting')
[2] CWE-89 Improper Neutralization of Special Elements used in an SQL
Command ('SQL Injection')
[3] CWE-
120
Buffer Copy without Checking Size of Input ('Classic Buffer
Overflow')
[4] CWE-
352 Cross-Site Request Forgery (CSRF)
[5] CWE-
285 Improper Authorization
[6] CWE-
807 Reliance on Untrusted Inputs in a Security Decision
[7] CWE-22 Improper Limitation of a Pathname to a Restricted Directory
('Path Traversal')
[8] CWE-
434 Unrestricted Upload of File with Dangerous Type
[9] CWE-78 Improper Neutralization of Special Elements used in an OS
Command ('OS Command Injection')
[10] CWE-
311 Missing Encryption of Sensitive Data
[11] CWE-
798 Use of Hard-coded Credentials
[12] CWE- Buffer Access with Incorrect Length Value
9.4 SANS TOP 25 SOFTWARE FOUTEN
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 58 -
805
[13] CWE-98 Improper Control of Filename for Include/Require Statement in
PHP Program ('PHP File Inclusion')
[14] CWE-
129 Improper Validation of Array Index
[15] CWE-
754 Improper Check for Unusual or Exceptional Conditions
[16] CWE-
209 Information Exposure Through an Error Message
[17] CWE-
190 Integer Overflow or Wraparound
[18] CWE-
131 Incorrect Calculation of Buffer Size
[19] CWE-
306 Missing Authentication for Critical Function
[20] CWE-
494 Download of Code Without Integrity Check
[21] CWE-
732 Incorrect Permission Assignment for Critical Resource
[22] CWE-
770 Allocation of Resources Without Limits or Throttling
[23] CWE-
601 URL Redirection to Untrusted Site ('Open Redirect')
[24] CWE-
327 Use of a Broken or Risky Cryptographic Algorithm
[25] CWE-
362
Concurrent Execution using Shared Resource with Improper
Synchronization ('Race Condition')
Voor een gedetailleerde beschrijving van deze risico’s wordt verwezen naar:
http://www.sans.org/top25-software-errors
Afstudeerscriptie: Betrouwbare applicaties realiseren
Versie : 2.0 - 59 -
A1: Injection
A2: Cross-sSite Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restict URL Access
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards
Voor een gedetailleerde beschrijving van deze risico’s wordt verwezen naar:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
9.5 OWASP TOP 10 RISICO’S