Betrouwbare applicaties realiseren

Afstudeerscriptie: Betrouwbare applicaties realiseren

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

-1-


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

-2-


INHOUDSOPGAVE 1

AANLEIDING.............................................................................................................................................. 4

2

DOEL, SCOPE EN AANPAK VAN HET ONDERZOEK ....................................................................... 6

3

2.1

DOELSTELLING ....................................................................................................................................... 6

2.2

SCOPE VAN HET ONDERZOEK .................................................................................................................. 7

2.3

AANPAK ................................................................................................................................................. 8

VOORONDERZOEK GERICHT OP HET ONTWIKKELEN EN ONDERHOUDEN VAN

BETROUWBARE APPLICATIES ................................................................................................................... 10

4

5

3.1

BETROUWBAARHEID VAN EEN SOFTWAREPRODUCT ............................................................................. 10

3.2

DE SOFTWARE DEVELOPMENT LIFE CYCLE. ........................................................................................ 13

3.3

ONDERZOEK NAAR MAATREGELEN....................................................................................................... 22

CONCEPTUEEL ONDERZOEKSMODEL ........................................................................................... 28 4.1

GEHANTEERDE PRINCIPES .................................................................................................................... 28

4.2

VOORGESTELDE MAATREGELEN ........................................................................................................... 31

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

-3-


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 OWASP3 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

-4-


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

-5-


2 DOEL, SCOPE EN AANPAK VAN HET ONDERZOEK 2.1 DOELSTELLING Met dit onderzoek willen we een bijdrage leveren, middels een stelsel van maatregelen, aan het realiseren en onderhouden van kwalitatief betrouwbare applicaties.

Centrale onderzoeksvraag:

Welke elementen en kenmerken bevat een Software Development Life Cycle (SDLC) waarmee met name het realiseren en onderhouden van betrouwbare applicaties wordt ondersteund?

Doelgroep

Het resultaat van het onderzoek zal voor twee doelgroepen bruikbaar zijn. Het management dat verantwoordelijk is voor het realiseren en onderhouden van betrouwbare applicaties en ITauditors die het framework als audit instrument, normenkader, kunnen gebruiken in hun werk.

Deelvragen

De centrale onderzoeksvraag wordt uitgesplitst naar de volgende drie deelvragen:

1.) Waaruit bestaat de Software Development Life Cycle en welke risico’s met betrekking tot betrouwbaarheid zijn daarin te onderkennen?

Vanuit de literatuur wordt gekeken uit welke processtappen een SDLC is opgebouwd. Tevens wordt onderzocht welke risico’s er onderkend kunnen worden bij het realiseren en onderhouden van betrouwbare applicaties.

2.) Welke maatregelen dienen genomen te worden in de SDLC om de betrouwbaarheid van applicaties te beheersen?

Wanneer duidelijk is welke risico’s er kunnen bestaan binnen de SDLC, wordt vanuit de literatuur gekeken naar maatregelen die een positieve bijdrage leveren aan het voorkomen hiervan, deze worden dan samengevoegd in een conceptueel model.

Versie

: 2.0

-6-


3.) Zijn de voorgestelde maatregelen toepasbaar in de praktijk en wat zijn de bevindingen?

Door middel van expert gesprekken willen we onderzoeken of het conceptueel model als relevant en toepasbaar wordt beschouwd door specialisten. Dit onderzoek voeren wij uit binnen een zeer groot softwarebedrijf waar gebruik wordt gemaakt van diverse technologie platformen en programmeertalen.

2.2 SCOPE VAN HET ONDERZOEK Productview

Bij softwareontwikkeling kunnen verschillende soorten software worden gemaakt, wij richten ons in dit onderzoek echter op applicaties. Onder een applicatie wordt toepassingssoftware verstaan dat onderdeel uitmaakt van een informatiesysteem. Een applicatie levert vanuit het informatiesysteem ondersteuning aan één of meer bedrijfsprocessen, daarom soms aangeduid als businessapplicatie.

4-lagen model B. Betz

In het vierlagenmodel van Betz wordt applicatie aangegeven met het begrip toepassing in de laag informatiesystemen.

Versie

: 2.0

-7-


De scope met betrekking tot de applicatie ligt op het kwaliteitsaspect betrouwbaarheid, wat we hieronder verstaan wordt onderzocht en toegelicht in hoofdstuk 3. Procesview

De software development life cycle bestaat uit een aantal processtappen. Voor dit onderzoek wordt gebruik gemaakt van de processtappen beschreven volgens Application Service Library (ASL), dit is een best practice voor software ontwikkeling en beheer. Door gebruik te maken van het ASL-kader sluit dit onderzoek aan bij de praktijk en zullen de verschillende processtappen herkenbaar zijn voor betrokken partijen.

2.3 AANPAK Vooronderzoek

Dit onderzoek begint met een theoretisch vooronderzoek. De fouten die in de aanleiding worden genoemd zijn symptomen van het feit dat in het proces van applicatieontwikkeling niet voldoende aandacht is geweest voor betrouwbaarheid in het algemeen en deze fouten. Daarom zijn er ook geen afdoende maatregelen zijn getroffen in het ontwikkel en beheer proces. 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

Versie

: 2.0

-8-


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

-9-


3 VOORONDERZOEK GERICHT OP HET ONTWIKKELEN EN ONDERHOUDEN VAN BETROUWBARE APPLICATIES Dit hoofdstuk richt zich op het vooronderzoek en bestaat uit drie onderdelen. Als eerste wordt het begrip betrouwbaarheid nader beschouwd. Omdat het hier om een kwaliteitskenmerk van een product gaat wordt de internationale ISO-norm 9126 gehanteerd. Vervolgens wordt het proces van softwareontwikkeling en onderhoud nader beschouwd op basis van het ASLframework. Als laatste wordt gekeken naar risico’s die zich in het proces kunnen voordoen dit in relatie tot het gewenst doel, productkwaliteit.

3.1 BETROUWBAARHEID VAN EEN SOFTWAREPRODUCT Als het doel is om betrouwbare applicaties te ontwikkelen en te onderhouden, dan is het van belang om het kwaliteitsbegrip betrouwbaarheid nader te beschouwen vooral omdat er diverse invalshoeken zijn om dit begrip te definiëren. Voor dit onderzoek wordt betrouwbaarheid zowel vanuit het vakgebied IT-auditing als vanuit het product benaderd.

IT-auditing

Informatie verwerking door een applicatie dient vanuit het bedrijfsproces gezien betrouwbaar te zijn. Betrouwbaarheid richt zich dan op het integer en vertrouwelijk behandelen van gegevens, tevens dienen de gegevens op de juiste momenten beschikbaar te zijn. Betrouwbaarheid is hier een kwaliteitseis gericht op de functionaliteit informatieverwerking. Binnen het IT-audit vakgebied spreekt men dan over confidentiality, integrity en availability (CIA)

ISO 9126

Betrouwbaarheid van een applicatie is een kwaliteitskenmerk van het product software. Voor softwarekwaliteit is de internationale ISO-norm 9126 beschikbaar als kader, we gebruiken dit kader ook voor ons onderzoek. In onderstaande figuur is een overzicht gegeven van de kwaliteitskenmerken die binnen deze ISO-norm worden onderkend.

Versie

: 2.0

- 10 -


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

- 11 -


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

Bedrijfszekerheid,

verholpen zijn en het systeem vrij blijft

Stabiliteit,

van storingen

Stabiliteit bij veranderingen

Foutbestendigheid

fault tolerance Mate waarin het systeem bestendig is

Robuustheid,

tegen bedoeld of onbedoeld onjuist

Bestendigheid

gebruik en tegen fouten in aanpalende

Fouttolerantie

systemen Beschikbaarheid

availability

Mate waarin het systeem op de gewenste tijden beschikbaar is voor de gebruiker

Degradeerbaarheid

Herstelbaarheid

degradability

Mate waarin de essentiële functies van het

Zelfherstellend

systeem blijven functioneren tijdens en na

vermogen,

storingen

Veerkracht

recoverability Gemak waarmee het systeem na uitval weer operationeel te maken is, zonder gegevensverlies

Beveiligbaarheid

Security

Mate waarin opzettelijk of abusievelijk

Beveiliging

ongeoorloofde toegang wordt voorkomen Juistheid

6

accuracy

Juistheid van de uitvoer van het systeem,

Nauwkeurigheid,

Voor een volledige lijst met definities wordt verwezen naar bijlage 9.1

Versie

: 2.0

- 12 -


Kenmerk6

Engels

Definitie


Stabiliteit

Stability

overeenkomstig de invoer en de

Plausibiliteit,

gespecificeerde bewerkingen.

Datakwaliteit

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

Supportability, Exploiteerbaarheid

kan worden. Wijzigbaarheid

changeability Gemak waarmee het systeem gecorrigeerd, gewijzigd en verbeterd kan worden.

Corrigeerbaarheid, Veranderbaarheid

3.2 DE SOFTWARE DEVELOPMENT LIFE CYCLE. Het softwareontwikkel- en onderhoudsproces bestaat uit een groot aantal activiteiten die te groeperen zijn naar een aantal hoofdprocessen. Een beschrijving van deze hoofdprocessen en activiteiten is te vinden in het Application Service Library (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)

Versie

: 2.0

- 13 -


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

- 14 -


Onderhoud en vernieuwing

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

Samenvattend onderkennen we de volgende risico’s; -

Nieuwe technologie brengt nieuwe (nog) onbekende risico’s met zich mee voor het bedrijfsproces;

-

Onduidelijkheid over welke infrastructuur gebruikt wordt door de applicatie;

-

Complexiteit van de applicatie zelf, waardoor impact van een wijziging moeilijk is vast te stellen.

10

College documentatie : Framework for application an d data security

Versie

: 2.0

- 15 -


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

- 16 -


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

- 17 -


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

- 18 -


Risico’s bij de acceptatietesten zijn vergelijkbaar met de risico’s in het testproces bij de ontwikkeling. Ook hier geldt bijvoorbeeld dat de acceptatieomgeving ‘productie like’ moet zijn. Zodra de applicatie door de verschillende partijen is geaccepteerd, is deze klaar om in productie genomen te worden. Om dit traject gecontroleerd te laten verlopen zijn er binnen ASL twee verbindende processen benoemd.

Samenvattend onderkennen we het volgende risico. -

Ondersteuning en acceptatie vindt niet of onvoldoende plaats met betrekking tot betrouwbaarheidseisen (volgens het programma van eisen)

Verbindende processen

Wijzigingenbeheer Wijzigingen hebben tot doel een applicatie te verbeteren, echter er schuilt ook een risico in het doorvoeren van een wijziging namelijk het optreden van incidenten in het algemeen en daarmee ook op het punt van betrouwbaarheid. Het is daarom van belang dat wijzigingen heel gecontroleerd worden uitgevoerd. Vooraf dient duidelijk te zijn wat het nut en de noodzaak is van een wijziging en wat de impact kan zijn voor de eerder genoemde drie domeinen (vraagzijde, aanbodzijde en infrastructuur) Wijzigingen dienen hierop te worden beoordeeld door het CAB13 voordat een wijziging geautoriseerd is om doorgevoerd te kunnen worden. Wijzigingen in software zijn in verschillende soorten te onderscheiden zoals een release, een patch of een technische update (leverancier) Het is van belang om deze verschillende type wijzigingen te onderkennen omdat de omvang, impact, urgentie hiervan verschillend is en dat daar de controlemaatregelen en goedkeuring op dienen te zijn afgestemd. Hoe gaat men bijvoorbeeld om met een update van JAVA, is dit een standaard wijziging of niet? Dit bepaald mede hoe de wijziging behandeld moet worden binnen wijzigingenbeheer. Omdat er bij het doorvoeren van een wijziging altijd het risico blijft bestaan dat er iets misloopt, met een onacceptabele impact voor één of meer domeinen, zal de behoefte bestaan om terug te gaan naar de oude situatie. Om dit mogelijk te maken zal een roll-back scenario ontworpen en getest moeten worden. Bij de impactanalyse zal bepaald worden of deze maatregel dient te worden getroffen. Belangrijk is het risico dat wijzigingen kunnen plaatsvinden buiten het proces wijzigingenbeheer om. Hierdoor kunnen diverse risico’s direct en op een later tijdstip ontstaan doordat geen zekerheid meer bestaat over de actuele situatie van de software. De integriteit kan

13

CAB = Change Advisory Board

Versie

: 2.0

- 19 -


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

- 20 -


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 OTAPomgeving zijn twee zaken van belang. Allereerst dienen de verschillende omgevingen voldoende logisch gescheiden te zijn zodat er eenduidigheid bestaat over waar het tussenproduct zich bevindt. Daarnaast dienen autorisaties(functiescheiding) en het gebruik daarvan (professionaliteit) in lijn te zijn met de scheiding tussen de OTAP-omgeving. Hiermee voorkomt men dat er onrechtmatige wijzigingen kunnen plaatsvinden op tussenproducten. Met andere woorden de integriteit van zowel de omgeving als het product dient gewaarborgd te zijn. Tevens is het van belang dat beleid voldoende geoperationaliseerd is naar MTHV’s zodat specialisten gefaciliteerd worden in de effectieve en efficiënte uitvoering hiervan. Het goed sturen op het gebruik van de MTHV’s kan preventief werken ten aanzien van het falen van de mens.


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

- 21 -


3.3 ONDERZOEK NAAR MAATREGELEN Voor de maatregelen zijn vanuit de literatuurstudie een aantal bronnen geselecteerd. De criteria die bij het selecteren van deze bronnen zijn gebruikt zijn openheid, actualiteit en validiteit. Daarnaast is er gezocht naar een evenwichtige verdeling met betrekking tot proces, product en personeel. De maatregelen moeten er in resulteren dat wordt voldaan aan de geselecteerde kenmerken van ISO 9126 en dat daarmee een betrouwbare applicatie kan worden gerealiseerd.

Software Assurance Maturity Model (SAMM)

SAMM is een maturity model voor software waarbij openheid en realiteitszin twee belangrijke uitgangspunten zijn. Het model werkt vanuit vier business functions via security practices naar activities en heeft als scope software development in brede zin. Eenvoudig, goed gedefinieerd en meetbaar zijn belangrijke principes binnen SAMM. De business functions sluiten aan op de processtappen van ASL. Governance sluit aan bij het sturende proces kwaliteitsmanagement construction heeft een relatie met de processen ontwerp en realisatie, verification met het testproces en deployment heeft een relatie met de verbindende processen van ASL en sluit aan bij de Impactanalyse. Vanuit de relatie met de processen van ASL selecteren we maatregelen die we kunnen gebruiken in het conceptueel model.

Building Security In Maturity Model (BSIMM)

BSIMM is een volwassenheidsmodel specifiek voor het realiseren van betrouwbare software. BSIMM noemt twee, voor dit onderzoek relevante, doelstellingen namelijk “Increased code quality” en “Clarity on what is the right thing to do for everyone involved in software security”. De eerste doelstelling sluit aan op productkwaliteit en de twee de geeft aan dat men in het

Versie

: 2.0

- 22 -


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

- 23 -


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

- 24 -


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

- 25 -


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

- 26 -


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

- 27 -


4 CONCEPTUEEL ONDERZOEKSMODEL Nadat in de vorige hoofdstukken de risico’s op betrouwbaarheid in beeld zijn gebracht willen we in dit hoofdstuk antwoord geven op de tweede deelvraag namelijk:

Welke maatregelen dienen genomen te worden in de SDLC om de betrouwbaarheid van applicaties te beheersen?

Geïnspireerd door D. Rook en Bateson die stelden dat het hanteren van principes de effectiviteit vergroot, hebben wij een vijftal principes gedefinieerd van waaruit de maatregelen zijn samengesteld. Een organisatie zou deze principes ook zelf kunnen hanteren. Het kunnen hanteren van principes is naar ons idee wel mede afhankelijk van de volwassenheid/ professionaliteit van een organisatie. Dit omdat principes geconcretiseerd dienen te worden naar de eigen praktijk. Maatregelen hebben het voordeel dat zij concreter zijn dan principes en kunnen daardoor een organisatie helpen om snel de eerste stappen te zetten in het realiseren en onderhouden van betrouwbare applicaties. Wij willen er wel op wijzen dat maatregelen niet dogmatisch gehanteerd dienen te worden als ‘vinklijstje’, uiteindelijk dient elke maatregel een bijdrage te leveren aan de doelstelling. Als een maatregel niet bijdraagt kan men teruggaan naar de gehanteerde principes en het te realiseren doel, om op basis daarvan een betere maatregel te nemen. Door het hanteren van maatregelen en principes binnen een SDLC kan een software ontwikkelen onderhoudsproces uitgroeien richting een Secure-SDLC. Dit begrip komt men steeds vaker tegen in literatuur19 waarmee aangegeven wordt dat er maatregelen genomen zijn ten behoeve van het realiseren en onderhouden van betrouwbare applicaties.

4.1 GEHANTEERDE PRINCIPES Principes geven enerzijds richting en anderzijds bieden zij ruimte voor eigen invulling. De richting is nodig om een organisatie in beweging te krijgen en ruimte doet recht aan de

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

Versie

: 2.0

- 28 -


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

- 29 -


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

- 30 -


meten van (tussen)resultaten. Omdat het doel en de te nemen maatregelen bekend zijn kan bepaald worden of en hoe er gestuurd moet worden. In het gehele traject van applicatie ontwikkeling en onderhoud zou men dit principe moeten hanteren, van functioneel ontwerp (incl. PvE) tot en met productie (monitoring/logging). Door dit principe te hanteren worden fouten in een zo vroeg mogelijk stadium ontdekt en de kans op ‘Building Security In’ het grootst, met als eindresultaat een betrouwbare applicatie.

Onderhoud dat wat betrouwbaar moet zijn Na acceptatie van de applicatie begint de productiefase, dit is de langste fase van de SDLC waarin een applicatie zich zal bevinden. Gedurende deze fase zullen er nieuwe bedreigingen en kwetsbaarheden ontstaan. Zowel de vraag- als aanbodzijde zullen zich hiervan bewust moeten zijn. Door het aspect betrouwbaarheid voldoende aandacht te blijven geven tijdens de productiefase, voorkomt men achterstallig onderhoud en blijft de applicatie betrouwbaar. Hiervoor is het nodig dat kwetsbaarheden en bedreigingen vanuit de verschillende domeinen actueel bijgehouden worden in het risico register, om tijdig wijzigingsvoorstellen in te kunnen dienen. Dit principe is bijvoorbeeld ook van toepassing op de kennis en kunde van het personeel, zij bepalen uiteindelijk de kwaliteit door de juiste maatregelen in het proces ten behoeve van het product te nemen.

4.2 VOORGESTELDE MAATREGELEN Vanuit de literatuur en met de principes in het achterhoofd hebben wij een stelsel van maatregelen opgesteld voor de SDLC, die in de case study getoetst zal worden. De maatregelen om de betrouwbaarheid te beheersen worden, om een overzichtelijk en gestructureerd geheel te krijgen, gegroepeerd naar de verschillende processtappen in ASL. Wie een maatregel moet uitvoeren is afhankelijk van hoe een SDLC binnen een organisatie is georganiseerd. In onderstaand figuur 1 is schematisch aangegeven waar de aandacht zich op richt in het ASL traject. De maatregelen in de eerste twee fasen richten zich vooral op de risico’s. Eerst inzicht krijgen in de risico’s en vervolgens eisen in het functioneel ontwerp stellen om deze risico’s te verkleinen. De volgende twee fasen richten maatregelen zich op het realiseren van betrouwbaarheid en het toetsen hierop. Nadat de acceptatie door de verschillende partijen (klant, applicatiebeheer en hosting) is afgerond, kan de applicatie in productie en zullen er weer nieuwe risico’s ontstaan. De feitelijke overgang van acceptatie naar productie dient gecontroleerd te

Versie

: 2.0

- 31 -


gebeuren via de verbindende processen. De maatregelen die daar genomen dienen te worden vormen in feite een aanvulling op de general IT-controls.

F IGUUR 1

De risico’s uit de productiefase vormen weer input voor de impactanalyse, waarmee de SDLC rond is. Maatregelen uit het sturende proces kwaliteit moeten dit proces op verschillende punten ondersteunen en aanvullen.

Onderhoud en vernieuwing

Maatregelen binnen de impactanalyse: Voer een business impact analyse uit voor het gebruik van de nieuwe applicatie, waarbij indien nodig ook een analyse wordt gemaakt met betrekking tot nieuwe technologie; Voer een risicoanalyse uit op zowel de ontwerp- als onderhoudsfase en betrek hierbij de gebruikte infrastructuur; Bepaal uit bovenstaande analyses welke betrouwbaarheidseisen (PvE) gesteld moeten worden, hanteer hierbij een classificatie Hoog/Midden/Laag; Actualiseer het risico register niet alleen voor de ontwerpfase maar zeker ook voor de productiefase (onderhoud). Hiervoor is monitoring en logging nodig in de productiefase, bijvoorbeeld Intrusion Detection en Prevention;

Maatregelen in het ontwerpproces De vraag- en aanbodzijde stellen gezamenlijk het FO op; Betrouwbaarheidseisen uit het PvE worden in het FO onderverdeeld naar:

Versie

: 2.0

- 32 -


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

- 33 -


Verbindende processen

Maatregelen in het proces wijzigen Een wijzigingsverzoek moet voorzien zijn van een impact/risico classificatie ten aanzien van betrouwbaarheid (samenwerking met het proces impactanalyse); Wijzigingen met impact/risico op betrouwbaarheid worden beoordeeld en geautoriseerd door de change advisory board (CAB); Alleen geautoriseerde wijzigingen worden geaccepteerd; Zorg voor een roll-back scenario. Maatregelen in het proces programmabeheer en distributie Definieer en onderhoud een definitieve software bibliotheek specifiek voor de verschillende OTAP20-omgevingen; Zorg voor een strikte scheiding van de OTAP omgevingen; Distributie wordt alleen uitgevoerd indien een roll-back beschikbaar is. kwaliteitsmanagement

Organisatie gerichte maatregelen Het management draagt visie en strategie uit, tevens benoemt zij doelstellingen en verantwoordelijkheden ten aanzien van betrouwbaarheid van applicaties; Betrouwbaarheidsdoelstellingen zijn opgenomen in de management PDCA21-cyclus; Medewerkers worden opgeleid zowel ten aanzien van (security) awareness als vak inhoudelijk, gedifferentieerd naar functie; Medewerkers worden opgeleid zowel ten aanzien van het uit te voeren proces als de te hanteren MTHV’s; Binnen de organisatie is een expert team software security, zij hebben een adviserende, controlerende en beoordelende taak in het voortbrengingsproces; Autorisaties dienen afgestemd te zijn op functies en rollen in de OTAP22-omgevingen.

20

OTAP = Ontwikkel, Test, Acceptatie en Productie

21

PDCA = Plan Do Check Act.

22

OTAP = Ontwikkel, Test, Acceptatie en Ontwikkel.

Versie

: 2.0

- 34 -


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

- 35 -


5 UITWERKING CASE STUDY 5.1 INLEIDING 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.

5.2 BEVINDINGEN ONDERHOUD EN VERNIEUWING 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

Versie

: 2.0

- 36 -


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

- 37 -


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

- 38 -


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.

5.3 BEVINDINGEN VERBINDENDE PROCESSEN 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

Versie

: 2.0

- 39 -


5.4 BEVINDINGEN KWALITEITSMANAGEMENT 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

Versie

: 2.0

- 40 -


(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.

5.5 ANALYSE 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

Versie

: 2.0

- 41 -


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.

5.6 CONCLUSIE 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.

5.7 AANBEVELINGEN 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;

Versie

: 2.0

- 42 -


3.) Bestuur het realiseren en onderhouden van betrouwbare applicatie middels een PDCAcyclus. 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

- 43 -


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 ISOnorm 9126 die wij geselecteerd hebben voor het begrip betrouwbaarheid zijn volwassenheid, foutbestendigheid, beschikbaarheid, degradeerbaarheid, herstelbaarheid, beveiligbaarheid, juistheid, stabiliteit, testbaarheid, beheerbaarheid en wijzigbaarheid. Risico’s zijn vervolgens beschreven ten aanzien van betrouwbaarheid en ASL, om vervolgens bij de tweede deelvraag uit te komen.

Welke maatregelen dienen genomen te worden in de SDLC om de betrouwbaarheid van applicaties te beheersen?

In de wetenschap dat medewerkers fouten maken zijn er maatregelen benoemd binnen de processtappen van ASL. Voor de maatregelen hebben wij literatuur bestudeerd en principes gehanteerd. Criteria ten aanzien van literatuur die wij stelden waren openheid, actualiteit en validiteit. Op basis hiervan zijn wij uitgekomen bij modellen van SAMM en BSIMM, de beveiligingsprincipes van OWASP, de ontwerpprincipes van David Rook. Tevens hebben we

Versie

: 2.0

- 44 -


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

- 45 -


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

- 46 -


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

- 47 -


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-volgensbateson-en-dilts/

Versie

: 2.0

- 48 -


9 BIJLAGEN 9.1 DEFINITIES EN SYNONIEMEN ISO 9126

Kenmerk

Engels

Definitie


FUNCTIONALITEIT

functionality

Mate waarin het

Effectiviteit

informatiesysteem functioneel correct is Geschiktheid

suitability

Mate waarin de gewenste

Functionaliteit (in

functies aanwezig zijn en

enge zin),

geschikt om gespecificeerde

Passendheid,

taken uit te voeren

Volledigheid, Compleetheid

Juistheid

accuracy

Juistheid van de uitvoer van

Nauwkeurigheid,

het systeem, overeenkomstig

Plausibiliteit,

de invoer en de

Datakwaliteit

gespecificeerde bewerkingen. Koppelbaarheid

interoperabilit

Gemak waarmee het systeem

y

gegevens kan uitwisselen

Connectiviteit

met andere systemen Functionele

compliance

standaardisatie

Mate waarin de

Standaardisatie,

functionaliteit en de

Inschikkelijkheid

gebruikersinterface zich conformeren aan standaarden die extern worden opgelegd (bedrijfsstandaarden, wetgeving, systeemgerelateerde afspraken) Beveiligbaarheid

security

Mate waarin opzettelijk of

Beveiliging

abusievelijk ongeoorloofde

Versie

: 2.0

- 49 -


Kenmerk

Engels

Definitie


toegang wordt voorkomen

Traceerbaarheid

traceability

Mate waarin herkomst en

Herleidbaarheid,

correcte verwerking van data

Controleerbaarheid

door het systeem op verschillende momenten in de verwerking gecontroleerd kan worden Localiseerbaarheid

niet in


extended ISO!

op locale omstandigheden

Inrichtbaarheid

(taal, karakterset, symbolen, wetgeving) aangepast kan worden.

BETROUWBAARHEID

reliability

Mate waarin het systeem blijft functioneren, ook tijdens storingen

Volwassenheid

Beschikbaarheid

maturity

availability

Mate waarin fouten en

Bedrijfszekerheid,

kinderziektes verholpen zijn

Stabiliteit,

en het systeem vrij blijft van

Stabiliteit bij

storingen

veranderingen

Mate waarin het systeem op de gewenste tijden beschikbaar is voor de gebruiker

Foutbestendigheid

fault tolerance

Mate waarin het systeem

Robuustheid,

bestendig is tegen bedoeld of

Bestendigheid

onbedoeld onjuist gebruik en

Fouttolerantie

tegen fouten in aanpalende systemen Degradeerbaarheid

degradability

Mate waarin de essentiële

Zelfherstellend

functies van het systeem

vermogen,

blijven functioneren tijdens

Veerkracht

en na storingen

Versie

: 2.0

- 50 -


Kenmerk

Engels

Definitie


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

Mate waarin het product is

Opm: dit is een

friendliness

afgestemd op de kennis en

apart subkenmerk,

ervaring van gebruikers

maar men kan terecht opmerken dat dit slechts een resultante is van andere subkenmerken.

Overzichtelijkheid

understand-

Gemak waarmee de

Begrijpelijkheid,

ability, clarity

gebruiker het concept en de

Begrijpbaarheid,

mogelijkheden van het

Duidelijkheid,

systeem kan overzien en

Toegankelijkheid

vinden Leerbaarheid

learnability

Snelheid waarmee een gebruiker de functies van het systeem kan leren gebruiken

Bedienbaarheid

operability

Snelheid en gebruiksgemak

Werkbaarheid,

voor (ervaren) gebruikers

Gebruiksgemak, Gebruikersgemak

Duidelijkheid

explicitness


Inzichtelijkheid

inzicht verschaft in de verwerkingsstatus (zandlopers, statusbar, …) Instelbaarheid

customisabilit

Mate waarin het systeem kan

Configureerbaarhei

y

worden ingesteld op wensen

d, Flexibiliteit,

van de gebruiker of de

Aanpasbaarheid

afdeling (voorkeursinstellingen, etc.)

Versie

: 2.0

- 51 -


Kenmerk

Engels

Definitie


Aantrekkelijkheid

attractiveness


Uitrustingsniveau,

door uiterlijk, gedrag en

Look en feel

service, tegemoetkomt aan vaak onuitgesproken gebruikersverwachtingen, ook voor esthetiek, mode, etc. Behulpzaamheid

helpfulness

Mate waarin helpfuncties beschikbaar zijn

EFFICIENTIE

Efficiency

Mate waarin het systeem met beschikbaar gestelde middelen presteert

Tijdsbeslag

Middelenbeslag

time

Responstijd,

Performance,

behaviour

transactiesnelheid, snelheid

Tijdgedrag

batchverwerking

Responsiesnelheid

resource

Hoeveelheid benodigde

Zuinigheid

behaviour

resources (netwerkcapaciteit, schijfruimte, geheugen; inen extern)

OVERZETBAARHEID

Portability

Mate waarin het systeem ook goed werkt op andere hardware/platformen

Aanpasbaarheid

adaptability


Overdraagbaarheid

overgezet kan worden naar een ander hardware/software-platform of naar een nieuwe versie daarvan

Installeerbaarheid

installability

Snelheid en gemak waarmee het systeem ge(de)installeerd kan worden

Technische standaardisatie

conformance

Mate waarin het systeem zich

Inschikkelijkheid,

houdt aan technische

Naleving

standaarden en afspraken, mede ten behoeve van de portabiliteit

Versie

: 2.0

- 52 -


Kenmerk

Engels

Definitie


Inpasbaarheid

replaceability

a. Het gemak waarmee het

Vervangbaarheid

systeem een bestaand systeem kan vervangen b. Mate waarin het systeem aansluit bij de bedrijfsprocessen en (handmatige) procedures

ONDERHOUD-

Maintainability

Maat voor het gemak waarmee het systeem onderhouden kan

BAARHEID Analyseerbaarheid

worden analysability

Gemak waarmee de oorzaak van

Fouttraceerbaarheid

fouten opgespoord kan worden en waarmee te wijzigen onderdelen kunnen worden gevonden

Wijzigbaarheid

changeability


Corrigeerbaarheid,

gecorrigeerd, gewijzigd en

Veranderbaarheid

verbeterd kan worden.

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

Supportability,

operationele staat gebracht en

Exploiteerbaarheid

gehouden kan worden.

Herbruikbaarheid

reusability

Mate waarin (delen van) het systeem herbruikbaar zijn in andere systemen

Schaalbaarheid

niet in extended


Scalability,

ISO!

uitgebreid kan worden bij een

Uitbreidbaarheid,

toenemend aantal gebruikers en

Extensibility

behoefte aan meer snelheid, verwerkings- en opslagcapaciteit

Versie

: 2.0

- 53 -


9.2 BESCHRIJVING OWASP PRINCIPES 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

Versie

: 2.0

- 54 -


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.

9.3

BESCHRIJVING BEVEILIGINGSPRINCIPES D. ROOK

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

Versie

: 2.0

- 55 -


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

- 56 -


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.

9.4 SANS TOP 25 SOFTWARE FOUTEN Rank

ID

[1]

CWE-79

[2]

CWE-89

[3]

CWE807 CWE-22 CWE-

[8]

434 CWE-78

[9]

CWE-

[10]

311 CWE-

[11]

798 CWE-

[12]

Versie

: 2.0

Command ('SQL Injection')

Overflow')

285

[7]

Improper Neutralization of Special Elements used in an SQL

120

CWE-

[6]

('Cross-site Scripting')

Buffer Copy without Checking Size of Input ('Classic Buffer

352

[5]

Improper Neutralization of Input During Web Page Generation

CWE-

CWE-

[4]

Name

Cross-Site Request Forgery (CSRF)

Improper Authorization

Reliance on Untrusted Inputs in a Security Decision Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Unrestricted Upload of File with Dangerous Type Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Missing Encryption of Sensitive Data

Use of Hard-coded Credentials Buffer Access with Incorrect Length Value

- 57 -


805 CWE-98

[13]

CWE-

[14]

129 CWE-

[15]

754 CWE-

[16]

209 CWE-

[17]

190 CWE-

[18]

131 CWE-

[19]

306 CWE-

[20]

494 CWE-

[21]

732 CWE-

[22]

770 CWE-

[23]

601 CWE-

[24]

327

[25]

Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion') Improper Validation of Array Index

Improper Check for Unusual or Exceptional Conditions

Information Exposure Through an Error Message

Integer Overflow or Wraparound

Incorrect Calculation of Buffer Size

Missing Authentication for Critical Function

Download of Code Without Integrity Check

Incorrect Permission Assignment for Critical Resource

Allocation of Resources Without Limits or Throttling

URL Redirection to Untrusted Site ('Open Redirect')

Use of a Broken or Risky Cryptographic Algorithm

CWE-

Concurrent Execution using Shared Resource with Improper

362

Synchronization ('Race Condition')

Voor een gedetailleerde beschrijving van deze risico’s wordt verwezen naar: http://www.sans.org/top25-software-errors

Versie

: 2.0

- 58 -


9.5 OWASP TOP 10 RISICO’S 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

Versie

: 2.0

- 59 -

Betrouwbare applicaties realiseren

Recommend Documents