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


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


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


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


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.


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


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


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


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.


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


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.


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


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.


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


Versie : 2.0 - 15 -


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


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.


- 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


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.


- Er wordt geen of onvoldoende richting gegeven in het technisch ontwerp aan het

kwaliteitsaspect betrouwbaarheid voor de te bouwen applicatie;

- Onvoldoende afstemming met infrastructuur over invulling betrouwbaarheid;

- De applicatiesoftware bevat programmeerfouten die kwetsbaarheden in de

betrouwbaarheid veroorzaken.

12 DMZ = DeMilitarized Zone


Versie : 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 ontwerpen 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.


- Testspecificaties en testontwerp is vanuit ontwerp en realisatie niet meegenomen;

- Testen richt zich niet of onvoldoende op het kwaliteitsaspect betrouwbaarheid;

- Testomgeving sluit onvoldoende aan op productie omgeving;

- Software updates van leveranciers worden niet zelf getest.

Implementatieproces

In het voorgaande testproces is idealiter aangetoond dat de applicatie is gerealiseerd volgens het

technisch ontwerp. Echter door de ontvangende partijen zal nog moeten worden vastgesteld dat

het resultaat ook voldoet aan het functioneel ontwerp inclusief het programma van eisen. De

ontvangende partij naast de vraagzijde is de aanbodzijde in de rol van technisch

applicatiebeheer en beheer infrastructuur. Alle drie de partijen hebben vanuit hun

verantwoordelijkheid eisen gesteld aan de applicatie. Tijdens het implementatieproces moeten

zij vaststellen dat er maatregelen getroffen zijn en dat die functioneren om de onderkende

risico’s te mitigeren. Om dit te kunnen vaststellen voeren de drie partijen acceptatietesten uit in

een speciaal hiervoor ingerichte omgeving. De aanbodzijde, in de rol van softwareleverancier,

levert ondersteuning bij het uitvoeren van deze acceptatietesten.


Versie : 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)


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


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.


- 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


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.


- Management geeft geen richting middels visie, strategie en doelstelling t.a.v.

betrouwbaarheid;

- Medewerkers zijn onbewust onbekwaam wanneer het gaat om betrouwbaarheid en het

realiseren daarvan in software;

- Beleidskader is niet of onvoldoende geoperationaliseerd naar MTHV’s;

- Er wordt niet goed gestuurd op het gebruik van MTHV’s;

- Functiescheiding is onvoldoende;

- Rollen en verantwoordelijkheden zijn niet duidelijk belegd in de organisatie.


Versie : 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


Versie : 2.0 - 23 -

proces maatregelen moet nemen om de menselijke fouten te beteugelen.Het model levert

daarmee een bijdrage aan de producten proceskwaliteit en heeft oog voor de menselijke factor.

Binnen BSIMM worden vier aandachtsgebieden (domains) gedefinieerd, vergelijkbaar met de

business functions van SAMM. Binnen deze aandachtsgebieden worden op basis van

doelstellingen drie hoofdactiviteiten genoemd. De hoofdactiviteiten worden vervolgens in drie

volwassenheidsniveaus verdeeld.

De maatregelen die in BSIMM worden genoemd overlappen qua strekking grotendeels de

maatregelen van SAMM. BSIMM is echter aanvullend op de volgende punten. Het belang van

commitment op senior management niveau wordt genoemd en de rol van het management om

dit over te brengen op het overige personeel. Tevens stelt BSIMM een “Software Security

Group” (SSG) voor die qua kennis en kunde een autoriteit is op het vakgebied en van daaruit

zowel uitvoerende, beoordelende en adviserende taken heeft. De SSG heeft als klankbord de

“Satellite” die wordt gevormd door ontwikkelaars met interesse voor software beveiliging.

Ontwikkel- en beveiligingsprincipes

Secure development principles (D. Rook)

SANS en OWASP geven inzicht waar risico’s zich bevinden en waar fouten gemaakt worden.

Wanneer het doel secure application development is, dan is het volgens D. Rook niet effectief

om software ontwikkelaars tot in detail alle potentiële fouten en risico’s te leren kennen. Het

voorkomen van programmeerfouten gaat volgens D. Rook effectiever wanneer ontwikkelaars

gebruik maken van negen secure ontwerpprincipes. Voor zijn negen principes hanteert hij als

basisprincipe KISS (Keep It Short and Simple). Dit idee sluit aan bij de veel gehoorde behoefte

aan complexiteitsreductie binnen de IT-wereld. De principes van D. Rook richten zich op de

techniek van het ontwerpen en programmeren. De principes zijn algemeen geformuleerd

waardoor ze toepasbaar zijn op meerdere ontwikkelmethoden en programmeertalen. Enerzijds is

dit een kracht, anderzijds moet de betrokken specialist wel een vertaling maken naar de eigen

situatie. De principes maken onderdeel uit van een SSDLC (Secure Software Development Life

Cycle), zoals weergegeven in onderstaand figuur.


Versie : 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


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)


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.


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


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


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


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


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


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


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.


Maatregelen binnen de impactanalyse:

� Voer een business impact analyse uit voor het gebruik van de nieuwe applicatie, waarbij

indien nodig ook een analyse wordt gemaakt met betrekking tot nieuwe technologie;

� Voer een risicoanalyse uit op zowel de ontwerp- als onderhoudsfase en betrek hierbij de

gebruikte infrastructuur;

� Bepaal uit bovenstaande analyses welke betrouwbaarheidseisen (PvE) gesteld moeten

worden, hanteer hierbij een classificatie Hoog/Midden/Laag;

� Actualiseer het risico register niet alleen voor de ontwerpfase maar zeker ook voor de

productiefase (onderhoud). Hiervoor is monitoring en logging nodig in de

productiefase, bijvoorbeeld Intrusion Detection en Prevention;

Maatregelen in het ontwerpproces

� De vraag- en aanbodzijde stellen gezamenlijk het FO op;

� Betrouwbaarheidseisen uit het PvE worden in het FO onderverdeeld naar:


Versie : 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.


Versie : 2.0 - 34 -


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.


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


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


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


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.


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


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


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


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

ontwikkelen 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


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.


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


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


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.


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.


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/


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/


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


Versie : 2.0 - 50 -


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


Versie : 2.0 - 51 -


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


Versie : 2.0 - 52 -


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


Versie : 2.0 - 53 -


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


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


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


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.


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


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


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

Betrouwbare applicaties realiseren - vurore.nl · 2 DOEL, SCOPE EN AANPAK VAN ... Daarom zijn wij...

Documents

Transcript of Betrouwbare applicaties realiseren - vurore.nl · 2 DOEL, SCOPE EN AANPAK VAN ... Daarom zijn wij...