IT Audit in een Web 2.0 Wereld - VUrORE...Deze scriptie tracht antwoord te geven op deze vragen en...

IT Audit in een Web 2.0 Wereld

Hoe kan een IT auditor overleven in een web 2.0 wereld?

Postgraduate IT audit opleiding, faculteit der economische wetenschappen en bedrijfskunde, Vrije Universiteit Amsterdam

ing. S. (Steven) Raspe, MSc.

[email protected]

ing. C. (Coen) Steenbeek, MSc. CISSP

[email protected]

9 oktober 2010

Versie 1.0.2


Coen Steenbeek & Steven Raspe 1

SAMENVATTING

Webapplicaties worden in toenemende mate gebruikt door bedrijven voor het verwerken van hun (gevoelige)

data. Om deze reden hebben wij onderzocht of IT auditors tijdens het beoordelen van webapplicaties extra

werkzaamheden moeten uitvoeren, wanneer een webapplicatie in scope van een audit valt. Het resultaat van

dit onderzoek hebben wij in deze scriptie vastgelegd.

Webapplicaties hebben een aantal specifieke eigenschappen ten opzichte van traditionele applicaties. Bij

webapplicaties wordt gebruik gemaakt van standaardmethoden, protocollen en scripttalen als HTTP, Javascript

en HTML. Deze protocollen zijn bij veel mensen bekend, doordat deze op internet veel gebruikt worden en op

een standaard manier worden ontwikkeld en geïmplementeerd. Hierdoor is ook veel bekend over de fouten

die door ontwikkelaars worden gemaakt bij het ontwikkelen, implementeren en onderhouden van

webapplicaties. Mede hierdoor is het mogelijk dat lijsten worden gepubliceerd op het internet, zoals de

OWASP top-10 [OWA10], die deze standaardfouten in webapplicaties beschrijven.

Door onder andere deze kwetsbaarheden en de vergrote bereikbaarheid van webapplicaties (webapplicaties

zijn eenvoudiger via het internet te benaderen/aan te bieden dan traditionele applicaties), is het risicoprofiel

van webapplicaties anders, zie hoofdstuk 3 voor een onderbouwing van deze redenering. Vanwege het

afwijkende risicoprofiel van webapplicaties zou de aanpak tijdens IT audits voor deze applicaties veranderd of

uitgebreid moeten worden. Wij zien echter in de praktijk dat de audit aanpak de laatste jaren nog niet is

aangepast op dit risicoprofiel.

Het is niet zo dat op dit moment geen goede methodieken bestaan om de beveiliging van webapplicaties te

onderzoeken. Zo zijn er methoden die IT Security professionals inzetten om de beveiliging van webapplicaties

te onderzoeken en te verbeteren. Wij zien echter in de praktijk dat veel verschillen bestaan tussen de aanpak

van IT security professionals en IT auditors op het moment dat een webapplicatie wordt beoordeeld.

Tijdens het praktijkonderzoek van deze scriptie zijn verschillende methodes naar voren gekomen die IT

security professionals inzetten voor het beoordelen van de beveiliging van webapplicaties. Deze methodes

verschillen van de technieken die IT auditors gebruiken. Zo beoordelen auditors naast de webapplicatie zelf

ook de ondersteunende processen en maatregelen zoals change management, waardoor de (technische)

werking van de webapplicatie zelf minder inhoudelijk beoordeeld wordt. IT security professionals zoomen veel

meer in op de werking en dan met name de veilige werking van de webapplicatie.

Wij zijn van mening dat de kans van het ontdekken van de standaardfouten in webapplicaties een stuk groter

is dan bij traditionele applicaties. Dit komt onder andere doordat het aantal mensen die de fouten kan

ontdekken veel groter is (zeker als de webapplicatie beschikbaar is op het internet). Ook is door het veelvuldig

gebruik van webapplicaties tooling ontwikkeld, die de standaardkwetsbaarheden in webapplicaties kan

achterhalen (zie hoofdstuk 3). Veel bedrijven laten beveiligingstesten uitvoeren waarmee deze

kwetsbaarheden ontdekt kunnen worden of nemen extra maatregelen in hun ontwikkelproces ter voorkoming

van deze kwetsbaarheden. Tijdens een IT audit kunnen de rapportages van de beveiligingstesten of de

maatregelen in het ontwikkelproces van een bedrijf beoordeeld worden. Op deze manier kan de IT auditor

inzicht krijgen in de veiligheid en betrouwbaarheid van de gegevensverwerking binnen webapplicaties, zodat

hier een beter oordeel over afgegeven kan worden. In gevallen dat deze informatie niet beschikbaar is, zal een

auditor een specialist kunnen gebruiken om een set van controles uit te voeren.

Wij zijn van mening dat een webapplicatie op een zelfde manier zou moeten worden benaderd als nu

bijvoorbeeld een besturingssysteem wordt benaderd. Specifieke risico’s en controle maatregelen die voor dit

besturingssysteem van toepassing zijn, moeten worden onderzocht (naast de standaardwerkzaamheden). Op



deze manier kunnen IT auditors, ondanks het andere risicoprofiel van webapplicaties, naar onze mening een

beter oordeel afgeven over de betrouwbare verwerking van gegevens en de veiligheid (vertrouwelijkheid,

integriteit en beschikbaarheid) van de (financiële) gegevens in de achterliggende database(s).

De ontwikkelingen rondom webapplicaties blijven steeds maar doorgaan. De applicaties worden dynamischer

en steeds meer applicaties worden beschikbaar gemaakt voor grotere groepen gebruikers. Als auditors

moeten wij deze trends en veranderingen nauwlettend volgen en onze werkzaamheden op deze

ontwikkelingen aanpassen, zeker wanneer bedrijfskritische applicaties met deze trends meegaan. Op deze

manier kunnen wij inspelen op de risico’s die deze ontwikkelingen met zich meebrengen.



INHOUDSOPGAVE

SAMENVATTING .............................................................................................................................................. 1

INHOUDSOPGAVE ............................................................................................................................................ 3

VOORWOORD .................................................................................................................................................. 4

1 INLEIDING ................................................................................................................................................ 5

1.1 VRAAGSTELLING ......................................................................................................................................... 6

1.2 ONDERZOEKSMETHODOLOGIE ....................................................................................................................... 6

1.3 AFBAKENING ............................................................................................................................................. 7

2 WEBAPPLICATIES & TRENDS .................................................................................................................... 8

2.1 WEB 2.0 EN WEBAPPLICATIES ....................................................................................................................... 8

2.1.1 Definitie: Webapplicaties .................................................................................................................. 8

2.1.2 Definitie: Web 2.0 ............................................................................................................................. 8

2.2 WEBAPPLICATIE TRENDS .............................................................................................................................. 9

3 RISICO’S IN EEN WEBAPPLICATIE OMGEVING ........................................................................................ 11

3.1 RISICO’S OF VERANDERINGEN IN HET RISICOPROFIEL ........................................................................................ 11

3.2 RISICO’S EN RISICOVERANDERINGEN OP BASIS VAN DE LITERATUURSTUDIE ........................................................... 11

3.2.1 Standaardkwetsbaarheden ............................................................................................................. 12

3.2.2 Bereikbaarheid ................................................................................................................................ 13

3.3 RISICO’S EN RISICOVERANDERINGEN OP BASIS VAN HET PRAKTIJKONDERZOEK ....................................................... 13

3.3.1 Ontwikkelproces ............................................................................................................................. 13

3.3.2 Onderhoud ...................................................................................................................................... 14

3.4 CONCLUSIES ............................................................................................................................................ 15

4 BEST PRACTICES VOOR BEVEILIGING IN EEN WEBOMGEVING ............................................................... 16

4.1 INFRASTRUCTUUR SECURITY........................................................................................................................ 16

4.2 APPLICATIE SECURITY ................................................................................................................................ 17

4.3 CONFIGURATIE SECURITY ........................................................................................................................... 18

4.4 SECURE SOFTWARE DEVELOPMENT .............................................................................................................. 18

4.5 SOURCE CODE SECURITY ............................................................................................................................ 19

5 DE IT-AUDITOR EN WEBAPPLICATIES ..................................................................................................... 21

5.1 AUDIT AANPAK ........................................................................................................................................ 21

5.2 BESTAANDE OPLOSSINGEN ......................................................................................................................... 21

5.3 PRAKTIJK ................................................................................................................................................ 22

6 ADVIES .................................................................................................................................................. 23

6.1 BEOORDELING BEVEILIGINGSTESTEN ............................................................................................................. 25

6.2 MATE VAN ZEKERHEID ............................................................................................................................... 27

7 CONCLUSIE ............................................................................................................................................ 28

7.1 CONCLUSIE ............................................................................................................................................. 28

7.2 VERVOLG ................................................................................................................................................ 29

APPENDIX I – BIBLIOGRAFIE ........................................................................................................................... 31

APPENDIX II – VERKLARENDE WOORDENLIJST ............................................................................................... 33

APPENDIX III – ENKELE BRONVERMELDINGEN ............................................................................................... 36

APPENDIX IV – VRAGENLIJST INTERVIEWS ..................................................................................................... 38



VOORWOORD

Dit onderzoek is uitgevoerd voor de afsluiting van de postgraduate IT audit opleiding. De auteurs van dit

document zijn beide studenten van de EDP audit opleiding aan de VU in Amsterdam. Het uitvoeren van dit

onderzoek was zonder onderstaande personen niet mogelijk geweest, daarom willen wij hierbij onze dank

uitspreken aan de volgende personen voor hun toegevoegde waarde in ons onderzoek:

• Kees van Hoof, voor de begeleiding en de discussies die ons telkens scherp hielden;

• Tom Schuurmans (Manager Security & Privacy team) voor de begeleiding vanuit Deloitte;

• Mirna Bognar (Manager Deloitte Security & Privacy team/IT Risk Manager ING) voor begeleiding

vanuit Deloitte en later vanuit ING;

• Erik van ’t Hoff (Controls Analyst), Dio Hemmelder (Senior Compliance Analyst) en Pelle

Aardewerk (Internal Audit Manager) vanuit een externe organisatie, Rob Christiaanse (Docent

Register EDP Audit opleiding aan de VU) en Tom Schuurmans (Manager Security & Privacy team)

voor de invulling van het initiële praktijkonderzoek;

• Sebastian Kremer (IT Security Architect) en Arthur Griesel (IT Auditor, internal audit) vanuit een

externe organisatie en Martijn Knuiman (IT Auditor Deloitte) voor de interviews ter toetsing van

onze conclusies en bevindingen.



1 INLEIDING

In september 2009 plaatst de Nederlandse website Security.nl het volgende artikel: “Hacker kraakt websites

ING, Dexia en HSBC” [SEC09]. Hierin wordt een succesvolle aanval door een Roemeense hacker beschreven,

die de webapplicaties of websites van 3 bedrijven heeft gekraakt (zie hoofdstuk 2 voor onze definitie van

webapplicaties). Door middel van een zogenaamde SQL-Injectie aanval wist de hacker toegang te verkrijgen tot

de achterliggende databases en kon op deze manier klantgegevens en andere vertrouwelijke informatie

bemachtigen.

Dit soort succesvolle aanvallen op bedrijfsapplicaties worden steeds vaker bekend en zorgen ervoor dat

bedrijven niet alleen financiële schade ondervinden, maar daarnaast ook negatief in het nieuws komen.

Hierdoor kan het bedrijf naast directe en indirecte financiële schade ook reputatieschade (imagoschade)

oplopen.

Webapplicaties zijn in de afgelopen jaren steeds vaker het doelwit van aanvallers en de voorspellingen zijn ook

dat dit steeds blijft groeien [RAM08]. Dit komt onder andere doordat in het laatste decennium deze

applicaties steeds belangrijker zijn geworden voor bedrijven: banken kunnen bijna niet meer bestaan zonder

een internetbankierdienst aan te bieden. Online winkels als bol.com en altavista.com krijgen al hun inkomsten

via hun webwinkels (zie hoofdstuk 2 voor de uitwerking van de trends rondom webapplicaties).

Hierdoor ontstaat steeds meer de behoefte om met meer detail webapplicaties te auditen en zal het

noodzakelijk zijn voor auditors om de nieuwe/veranderende beveiligingsrisico’s (hoofdstuk 3) op

webapplicaties te volgen en te controleren tijdens de IT audits.

Binnen Deloitte zijn wij, Steven Raspe en Coen Steenbeek, werkzaam in het Security & Privacy Team (S&P

team). Vanuit het S&P team voeren wij, naast IT Audits, adviesopdrachten uit met de focus op

netwerkbeveiliging, de beveiliging van besturingssystemen en de beveiliging van (web)applicaties.

Gedurende het uitvoeren van IT audits en adviesopdrachten zien we in toenemende mate dat klanten gebruik

maken van webapplicaties. Dit kan in de vorm zijn van een financieel pakket zoals SAP (via een extra web-

schil), maar ook Microsoft maakt tegenwoordig haar office pakket beschikbaar via een “webapplicatie”

[PER09]. In hoofdstuk 2 beschrijven wij de verschillende trends van het gebruik van webapplicaties. Door dit

type applicaties vervagen de grenzen van het bedrijfsnetwerk. Webapplicaties die gebruikt worden voor

bedrijfsdoeleinden kunnen ook van thuis-PC’s of andere privé apparaten met een webbrowser worden

opgestart. Er hoeft immers geen onderdeel van de applicatie vooraf lokaal te worden geïnstalleerd (behalve

een webbrowser die standaard op de meeste PC’s, Tablets, Laptops of Smartphones geïnstalleerd staat),

alvorens de applicatie kan worden gebruikt. Oftewel, de bereikbaarheid en beschikbaarheid van de applicaties

en daardoor de achterliggende gegevens wordt vele malen groter.

Wij zijn van mening dat het gebruik van webapplicaties en alles wat daarmee samenhangt, significante

gevolgen heeft voor de beveiliging van de gevoelige gegevens van een bedrijf. Dit heeft ook gevolgen voor de

audit en de auditaanpak die een IT auditor kiest bij het beoordelen van deze applicaties (zie hoofdstuk 5 voor

een onderbouwing hiervan). Hoe kan een bedrijf gebruik maken van webapplicaties en toch hetzelfde

veiligheidsniveau bieden als traditionele applicaties die alleen via het eigen netwerk benaderd kunnen

worden? Hoe dienen bedrijven om te gaan met alle aanvallen op webapplicaties? Welke extra maatregelen

moeten genomen worden in de ontwikkelprocessen van bedrijven? Wat zijn de veranderingen in de

werkzaamheden van auditors door het toenemende gebruik van webapplicaties?

Deze scriptie tracht antwoord te geven op deze vragen en beschrijft de extra werkzaamheden die een auditor

zou moeten uitvoeren voor een audit van een webapplicatie (zie hoofdstuk 6).



1.1 VRAAGSTELLING

Dit document beschrijft de invloed van webapplicaties op de audit aanpak van auditors. Om de hypothese dat

het auditen van webapplicaties beter en efficiënter kan, hebben we de volgende hoofdvraag gesteld:

“Op welke wijze dient de informatiebeveiliging rondom webapplicaties geregeld te worden en welke

beheersmaatregelen vereisen specifieke aandacht tijdens een IT audit?”

Om deze hoofdvraag te beantwoorden, hebben wij eerst onderzoek gedaan naar de volgende deelvragen. Met

de antwoorden uit deze vragen wordt de hoofdvraag beantwoord:

1. Wat zijn de huidige trends t.a.v. webapplicaties?

2. Welke (informatiebeveiligings)risico’s bestaan bij het gebruik van webapplicaties?

3. Welke risico’s worden nu veelal afgedekt en welke maatregelen worden daarvoor genomen?

4. Welke risico’s met betrekking op webapplicaties blijven in veel bedrijven onderbelicht tijdens een IT audit,

wat is de reden hiervan en wat kunnen de gevolgen hiervan zijn?

5. Bestaan aanvullende manieren waarop auditors meer ‘zekerheid’ kunnen krijgen bij de beoordeling van

webapplicaties?

1.2 ONDERZOEKSMETHODOLOGIE

De onderzoeksmethode die wij hebben gekozen om antwoord te kunnen geven op de hoofd- en deelvragen

bestaat uit een combinatie van een literatuurstudie aangevuld met een praktijkstudie. De interviews voor deze

praktijkcasus zijn gehouden met een aantal experts op het gebied van webapplicaties en IT Auditing. De

resultaten hiervan zijn in dit document beschreven.

Op basis van een literatuurstudie is nagegaan in hoeverre al onderzoek is gedaan naar het onderwerp. Met

behulp van publicaties is een beeld gevormd van de huidige trends ten aanzien van webapplicaties. Deze

literatuurstudie richt zich vooral op de eerste 2 deelvragen van dit onderzoek.

Met betrekking tot de inventarisatie van de risico’s is naast de al onderkende risico’s of risicoveranderingen

door ons, ook een praktijkcasus uitgewerkt. Voor deze praktijkcasus hebben wij bij twee grote internationale

bedrijven met zowel IT security als audit professionals gesproken (helaas is het niet mogelijk deze bedrijven bij

naam te noemen). Door interviews te organiseren met een aantal senior personen binnen deze multinationals,

hebben wij een goed beeld kunnen krijgen van de beveiligingsrisico’s en de manier van auditen. Om de

inventarisatie van de beveiligingsrisico’s vanuit verschillende standpunten te benaderen, hebben wij ook een

externe subject matter expert en een externe IT auditor geïnterviewd. Wij hebben ervoor gekozen om een zo

breed mogelijk beeld te krijgen door interne en externe IT security professionals en IT auditors te interviewen.

Op deze manier hebben wij zowel binnen de onderzochte bedrijven en als buitenstaander, die inzicht heeft in

de situatie bij veel verschillende bedrijven, verschillende standpunten van de IT security professional en de

auditor verkregen.

De interviews met de audit professionals en IT security professionals zijn naast de risico-identificatie, ook

gebruikt om een beeld te krijgen over welke risico’s binnen bedrijven (specifiek) voor webapplicaties worden

onderkend. Zie appendix IV voor de vragenlijst die gebruikt is bij de interviews.



De resultaten van dit onderzoek zijn in combinatie met het literatuuronderzoek de input voor de

beantwoording van de 4e en 5

e deelvraag van dit onderzoek. We hebben de resultaten gebruikt om te toetsen

tegen welke problemen de IT-Auditor kan aanlopen bij het beoordelen van een webapplicatie. Daarnaast

hebben wij de meest efficiënte methodes, zowel met behulp van de literatuurstudie alsmede de case studie en

eigen ervaringen, onderzocht. Uiteindelijk zijn wij tot een oplossing gekomen om tijdens een IT audit een

redelijke mate van zekerheid te verkrijgen over de juiste verwerking van gegevens en de security van een

webapplicatie.

Door deze resultaten met een IT Architect, een internal auditor en een external auditor bij een tweede

multinational te bespreken, is bevestigd dat de conclusies die we in deze scriptie trekken worden herkend en

deze bedrijven kunnen helpen met het geven van focus aan de IT audit werkzaamheden. Bij deze bespreking is

naar voren gekomen dat dit tweede bedrijf reeds bezig is met het implementeren van een gedeelte van de

oplossing die wij hebben besproken. Daarnaast heeft men aangegeven de overige aanbevelingen zeker te

zullen overwegen.

Door literatuuronderzoek te combineren met een praktische casus denken we een goede basis te leggen voor

onze scriptie. Het literatuuronderzoek, in het bijzonder op het gebied van de bestaande richtlijnen op het IT

auditing, is erop gericht naar voren te laten komen hoe op dit moment wordt gekeken naar de beveiliging van

webapplicaties. Door dit te koppelen aan een praktische case denken wij een aantal risico’s te kunnen

identificeren die op dit moment onderbelicht blijven tijdens IT audits.

De resultaten van deze twee onderzoeken zijn gebruikt om een efficiënte methode te beschrijven met als doel

de belangrijkste geïdentificeerde risico’s in webapplicaties te identificeren.

1.3 AFBAKENING

De webapplicaties die in dit onderzoek zijn onderzocht, hebben allen een significante impact op de

bedrijfsvoering van een organisatie. Binnen de webapplicaties die in dit document beschreven worden, geldt

dat:

• Bedrijfskritische of vertrouwelijke gegevens worden opgeslagen;

• Transacties worden verwerkt die kritisch zijn voor de bedrijfsvoering.

Deze bovenstaande gegevens worden vaak opgeslagen in achterliggende databases zoals beschreven wordt in

hoofdstuk 2. De beveiliging of de auditaanpak voor de beoordeling van een database zullen wij in dit

document niet beschrijven (deze zijn reeds uitvoering beschreven in andere documentatie). Wij zullen hierbij

alleen naar de verwerking en het opvragen van de gegevens door de webapplicatie kijken en hoe deze door de

applicatie aan het Database Management System (DBMS) wordt aangeboden.

De definitie van webapplicaties en Web 2.0 die in dit document wordt gehanteerd, is beschreven in hoofdstuk

2.

Daarnaast zijn de risico’s of risicoveranderingen die wij in dit onderzoek onderkennen geen uitputtende lijst.

Dit zijn louter de veel voorkomende risico’s/veranderingen die naar voren zijn gekomen in het

literatuuronderzoek, het praktijkonderzoek en onze eigen ervaring.



2 WEBAPPLICATIES & TRENDS

In dit hoofdstuk worden de verschillende verschijningsvormen van webapplicaties besproken en de trends die

webapplicaties de afgelopen jaren hebben doorgemaakt.

2.1 WEB 2.0 EN WEBAPPLICATIES

Sinds het begin van het computertijdperk is de behoefte geweest computers en applicaties met elkaar te laten

communiceren. Bij de eerste applicaties was over het algemeen sprake van een zeer zware server

(bijvoorbeeld mainframe of iSeries) die al het werk uitvoerde en minimale clients, die niets meer deden dan

beeld weergeven (de terminals).

Vervolgens ontstond de trend om de applicatie steeds meer naar de werkstations te verplaatsen, doordat de

werkstations steeds meer rekenkracht kregen. Deze trend is echter in de laatste jaren omgekeerd; applicaties

worden steeds meer teruggebracht naar de server.

Een zeer bekende en nog steeds de meest succesvolle toepassing hiervan is de webserver met de internet

browser. Toen de mogelijkheid ontstond om “dynamische” webpagina’s te creëren, ontstond ook de

mogelijkheid applicaties te maken waarvan de enige cliënt software een webbrowser was (met eventueel

additionele software als Java of Flash geïnstalleerd). Dynamische webpagina’s zijn pagina’s die worden

gegenereerd op het moment dat de bezoeker de webpagina opvraagt, waarbij dezelfde pagina voor elke

gebruiker of elke keer dat deze wordt opgevraagd andere content kan bevatten. Hieruit is de term Web 2.0

geboren.

Aangezien de meningen over de definities van Web 2.0 en webapplicaties nogal verschillen, zullen wij in het

kader van deze scriptie de volgende definities gebruiken:

2.1.1 DEFINITIE: WEBAPPLICATIES

Onder webapplicaties verstaan wij: “alle interactieve applicaties die door een gebruiker middels een web-

browser zijn te benaderen over het HTTP of HTTPS protocol.”

Om tot deze definitie te komen hebben we op basis van een aantal verschillende definities op het internet

[GOO10], een definitie vastgesteld die het beste het object weerspiegelt die met de onderzoeksvraag wordt

beoogd.

2.1.2 DEFINITIE: WEB 2.0

Het begrip Web 2.0 heeft veel verschillende definities en blijft een ongrijpbaar begrip. Wat veel definities

gemeen hebben is dat Web 2.0 wordt gebruikt om het hedendaagse (2010) internet aan te duiden. Hierbij

wordt met name gedoeld op interactieve services die via het web worden aangeboden en werken zonder

voorgeïnstalleerde applicaties aan de client kant, met uitzondering van een webbrowser en eventueel een

aantal plug-ins hiervoor (zoals Flash en Java). Centraal in deze gedachte staat dat iedereen naar eigen wens

informatie toe kan voegen en toegang kan verkrijgen tot informatie die anderen hebben toegevoegd. Voor

meer informatie verwijzen we graag door naar de Web 2.0 webapplicatie Wikipedia [WIK10].

Het argument kan worden gevoerd dat de term webapplicaties meer omvat, zoals applicaties als Google Earth,

Microsoft Office Live Workspace of scripts die zonder grafische interface via HTTP en HTTPS informatie

opvragen. Wij zijn echter van mening dat in het verband van deze scriptie dit type applicaties weinig aan de

kwaliteit van dit onderzoek toe zullen voegen, terwijl de complexiteit wel aanzienlijk groter wordt.



Uit discussies met IT security experts en IT auditors vanuit de praktijk, is naar voren gekomen dat de drempel

lager wordt voor gebruikers om gebruik te maken van webapplicaties. Dit is één van de redenen waarom

bedrijven voor webapplicaties kiezen ten opzichte van traditionele applicaties en heeft de volgende oorzaken:

• Veel gebruikers zijn bekend met de werking van webpagina’s, waardoor zij sneller vertrouwd

raken met de gebruikersinterface;

• Geen speciale software of installatieprocedure is benodigd, voordat een gebruiker kan starten

met het gebruik van het programma (alleen een OS met een webbrowser). Voor sommige

webapplicaties dient aanvullende software als Java of Flash geïnstalleerd te worden, dit is echter

de keuze van de ontwikkelaars en/of de bedrijven en wordt vaak alleen om esthetische redenen

gekozen. Dit kan de onderhoudbaarheid van de webapplicaties complexer maken, desondanks is

dit nog steeds eenvoudiger dan tientallen lokaal geïnstalleerde applicaties op werkstations;

• Applicaties kunnen eenvoudiger voor meerdere locaties beschikbaar worden gesteld.

Daarnaast is uit praktijkervaring, die wij tijdens onze werkzaamheden voor Deloitte hebben opgedaan en de

literatuurstudie [OFF02], gebleken dat nog een aantal andere voordelen bestaan, waardoor in toenemende

mate voor webapplicaties wordt gekozen:

• Alle updates van de software kunnen centraal plaatsvinden op de server, waardoor de gebruikers

altijd met de nieuwste versie werken (onderhoudbaarheid). Uitzondering hierop is de

webbrowser die standaard op bijna iedere computer is geïnstalleerd en vaak een eigen update

mechanisme heeft;

• Doordat de logica van de applicatie grotendeels aan de kant van de server zit, wordt het minder

afhankelijk van de snelheid van de client computer aan de gebruikerskant en is de applicatie

gemakkelijker te beheren en uit te breiden (schalen). (Niet alle logica wordt aan de server kant

uitgevoerd, zo kunnen bepaalde bewerkingen aan de client kant worden uitgevoerd bijvoorbeeld

met behulp van Javascript). De schaalbaarheid wordt vereenvoudigd, aangezien het mogelijk is

de capaciteit van de webapplicatie te vergroten. Dit kan worden bereikt door enkel een extra

webserver met dezelfde webapplicatie te plaatsen in combinatie met een mechanisme wat de

gebruiker naar de minst drukke server stuurt (load balancing).

2.2 WEBAPPLICATIE TRENDS

Door de voordelen die in paragraaf 2.1 naar voren zijn gekomen, zijn er steeds meer organisaties die

applicaties beschikbaar maken via een webbrowser. Denk hierbij aan Google, die een complete set aan

services middels webapplicaties aanbiedt1. Ook zijn er steeds meer traditionele applicaties, soms zelfs stand-

alone applicaties, die worden omgevormd naar webapplicaties [MAC08].

Daarnaast zijn nog steeds ontwikkelingen gaande op het gebied van webapplicaties. Zo wordt steeds meer

software “web-enabled” gemaakt en als online dienst aangeboden, dit wordt Software as a Service of afgekort

SaaS genoemd. SaaS wordt ook vaak gezien als onderdeel van het populaire Cloud Computing [BUY08].

Het is echter zo dat naarmate de functionaliteit van applicaties toeneemt, ook de complexiteit van de

applicatie toeneemt, waardoor de kans op kwetsbaarheden in de applicatie ook wordt vergroot. Er kan echter

niet worden aangenomen dat de complexiteit van een applicatie toeneemt als de applicatie via een

1 Zie hier voor een overzicht van de set: http://www.google.nl/intl/nl/options/



webbrowser kan worden benaderd. Wel blijkt uit artikelen als bijvoorbeeld “Web application attacks”

[WAT07] dat het gebruik van webapplicaties extra kwetsbaarheden kan introduceren.

Steeds vaker komt in het nieuws dat aanvallen plaatsvinden op webapplicaties bij bedrijven. In het volgende

hoofdstuk worden de gevolgen hiervan beschreven. Hieronder staan een aantal voorbeelden hiervan:

• In december 2007 is van een onbekend aantal klanten van de populaire technologie webshop

Geeks.com de klantgegevens gestolen. Het is hackers gelukt op de e-commerce site van

Geeks.com binnen te dringen en onder andere de naam, het adres, het e-mailadres, het

telefoonnummer en de creditcardgegevens te bemachtigen [WAL08].

• Mozilla heeft de eigen webwinkel enige tijd moeten sluiten in augustus 2009 nadat hackers hier

wisten in te breken. Hoeveel klanten getroffen zijn is niet bekend gemaakt, maar om misbruik te

voorkomen, is store.mozilla.org tijdelijk gesloten geweest. De Open Source ontwikkelaar

ontdekte dat GatewayCDI (de derde partij die de backend voor de Mozilla Store regelt) via de

webapplicatie gehackt was. Mozilla zou GatewayCDI hebben aangemoedigd [MOZ09] om alle

betrokken individuen wiens gegevens gestolen zijn zo spoedig mogelijk te informeren [SEC09-2].

Bij webapplicaties wordt het aanvallen echter een stuk eenvoudiger, aangezien deze vaak beschikbaar worden

gemaakt op het internet. Deze en andere oorzaken hiervoor zijn:

• Webapplicaties zijn eenvoudiger te benaderen (zie de punten genoemd in paragraaf 3.2.2);

• Een aantal ’standaard’ zwakheden bestaan in de programmeertalen die veel worden gebruikt

voor het maken van webapplicaties. Vaak worden deze standaard zwakheden niet afgevangen

tijdens de ontwikkeling van de webapplicatie (Een top 10 van zwakheden is opgesteld door de

OWASP organisatie, zie ook paragraaf 3.2.1);

• Webapplicaties maken aan de client kant veelal gebruik van script talen in plaats van binaries of

executables. Aangezien deze veel eenvoudiger zijn te begrijpen en aan te passen is het

eenvoudiger applicatie controles te omzeilen.



3 RISICO’S IN EEN WEBAPPLICATIE OMGEVING

In hoofdstuk 2 is een aantal voor- en nadelen voor het gebruik van webapplicaties beschreven. De voordelen

kunnen echter ook extra risico’s met zich meebrengen. Deze zullen we in dit hoofdstuk uiteenzetten op basis

van een literatuurstudie, de twee praktijkcasussen en onze kennis en ervaring uit de praktijk.

3.1 RISICO’S OF VERANDERINGEN IN HET RISICOPROFIEL

In de context van deze scriptie splitsen we de verschillende IT risico’s uit naar twee aspecten:

• Kans: De kans dat een scenario plaatsvindt (of een kwetsbaarheid succesvol wordt misbruikt);

• Impact: De gevolgen als het hierboven genoemde scenario plaatsvindt.

Op basis van de kans maal de impact kan een IT risico worden bepaald (zoals deze ook wordt gebruikt door

ISO, NIST en FAIR; zoals te lezen in [OSA10]).

De risico’s of veranderingen in het risicoprofiel die in dit hoofdstuk zijn onderkend, zijn risico’s die of specifiek

van toepassing zijn op webapplicaties dan wel significant anders zijn ten opzichte van traditionele applicaties.

Overige risico’s op softwareapplicaties, zoals een te ruime inrichting van de rechten binnen een applicatie door

inadequaat autorisatiebeheer dat kan leiden tot functievermenging, zijn uiteraard ook van toepassing op

webapplicaties. Deze zijn hier niet gespecificeerd omdat deze niet significant verschillen van de risico’s op

traditionele applicaties.

In onderstaande figuur staat een overzicht van een standaardinrichting van de infrastructuur rondom een

webapplicatie. Deze applicatie wordt aangeboden via een netwerk en bevat een database, die op een aparte

server is geplaatst. De pijlen boven de figuur geven de plaatsen aan waar zich risico’s kunnen voordoen. De

client kan in dit geval elk apparaat zijn dat over een web browser beschikt en hoeft dus niet per definitie een

PC te zijn. Webbrowsers zijn tegenwoordig ook beschikbaar op bijvoorbeeld spelcomputers, iPads,

Smartphones, of TV’s.

3.2 RISICO’S EN RISICOVERANDERINGEN OP BASIS VAN DE LITERATUURSTUDIE

In deze paragraaf beschrijven we de belangrijkste risico’s of veranderingen in het risicoprofiel van applicaties

die worden geïntroduceerd bij het gebruik van webapplicaties.

Risico

Risico

Risico

Risico

Risico

FIGUUR 1 - DE RISICO'S VAN WEBAPPLICATIES DOEN ZICH VOOR OP MEERDERE POSITIES



3.2.1 STANDAARDKWETSBAARHEDEN

Een voordeel van webapplicaties is het gebruik van standaardsoftware aan de kant van de client (de

webbrowser). Een client heeft in principe alleen een webbrowser nodig om gebruik te kunnen maken van de

services die een webapplicatie biedt. Het is een voordeel dat geen speciale software meer nodig is voor het

gebruik, omdat de installatie en het onderhoud van de client applicaties niet meer nodig is. Updates voor de

applicatie worden aan de serverkant (en dus eenzijdig) uitgevoerd en vanaf dat moment is de update

doorgevoerd voor alle gebruikers. Daarnaast wordt de meeste rekenkracht uitgevoerd op de servers,

waardoor de systeemeisen voor het werkstation van de gebruiker lager zijn. Desondanks moet er voor

sommige webapplicaties die bijvoorbeeld gebruik maken van Java, Silverlight of Flash, nog software

geïnstalleerd worden op een client. De hoeveelheid van deze software is echter zeer beperkt en staat niet in

vergelijking met lokale installaties van applicaties.

De mogelijkheid om gebruik te maken van standaardsoftware wordt mede mogelijk gemaakt door het gebruik

van standaard protocollen en scriptingtalen, zoals HTML, http en Javascript. Door het benutten van onder

andere standaardprotocollen en standaard scriptingtalen, wordt het gebruik van standaard software mogelijk.

Voor het gemak noemen wij alle gebruikte standaarden in dit document standaardprotocollen. In de

specificaties van standaardprotocollen, die publiek beschikbaar zijn, staat precies gedefinieerd hoe applicaties

met elkaar kunnen/moeten communiceren. Standaardprotocollen in dit verband zijn protocollen die worden

gebruikt op applicatie niveau om te communiceren met een webapplicatie.

De script- of programmeertalen bij webapplicaties zijn daarnaast veel eenvoudiger te begrijpen en te lezen dan

binaries of executables. Om deze reden wordt het eenvoudiger voor personen om webapplicaties te

ontwikkelen. Hierdoor is het echter ook eenvoudiger deze applicatie aan te passen en daarmee de eventuele

controles te omzeilen.

Webapplicaties zijn in het bijzonder vatbaar voor standaardaanvallen die ontstaan door veel gemaakte

beveiligingsfouten tijdens het ontwikkelen en implementeren van dit type applicatie (zie hiervoor ook de

OWASP Top 10 [OWA10]). Al deze standaardaanvallen zijn dreigingen waaraan een webapplicatie wordt

blootgesteld. TABEL 1 geeft een paar van deze top 10 kwetsbaarheden en wat de dreiging behorende bij deze

kwetsbaarheden is. De volledige tabel kan worden gevonden op [TOP10].

TABEL 1 DREIGINGEN UIT DE OWASP TOP-10

Dreiging Uitleg

A1: Injection

Wanneer de gebruikersinvoer van webapplicaties niet voldoende wordt

gevalideerd en rechtstreeks wordt uitgevoerd op een server, bestaat de

mogelijkheid, dat aanvallers direct commando’s uitvoeren of ongeautoriseerde

toegang verkrijgen tot de data in een database of op het besturingssysteem.

Hierdoor kunnen ongeautoriseerde wijzigingen plaatsvinden in de gegevens of

kunnen aanvallers de (kritische) gegevens in de database inzien.

A2: Cross-Site Scripting

(XSS)

XSS kan voorkomen binnen een applicatie wanneer de invoer van een gebruiker

niet voldoende wordt gevalideerd. Door middel van XSS kan een aanvaller scripts

uitvoeren in de browser van een gebruiker, waardoor de aanvaller bijvoorbeeld de

sessie van een gebruiker kan overnemen of gebruikers naar phising sites sturen.

A5: Cross-Site Request

Forgery (CSRF)

Door middel van een CSRF aanval, kan een aanvaller acties uitvoeren via de

browser van een gebruiker. Door een vooraf bepaald commando naar een

slachtoffer te sturen, kan de webbrowser worden gebruikt om uit naam van het

slachtoffer commando’s uit te voeren op de webapplicatie Hierdoor zou

bijvoorbeeld een aanvaller een bankbetaling kunnen uitvoeren uit naam van een

slachtoffer.



A8: Failure to Restrict

URL Access

Door middel van het URL veld in een browser kan een bepaalde URL worden

opgevraagd. Webapplicaties dienen voor elke URL adequate toegangscontrole in

te bouwen, omdat door middel van manipulatie van de URL in de adresbalk van de

webbrowser, achterliggende URL’s direct benaderd kunnen worden. Op deze

manier kunnen ook URL’s benaderd worden waarvoor een gebruiker

geautoriseerd zou moeten zijn en dus ongeautoriseerde toegang kan worden

verkregen tot deze pagina’s als dit niet goed wordt afgeschermd.

Deze standaardkwetsbaarheden vergroten de kans dat een webapplicatie wordt getroffen door een aanval van

buitenaf. De impact van deze kwetsbaarheden is echter verschillend, omdat dit per type webapplicatie

verschilt. Indien een webapplicatie gebruikt wordt als Content Management Systeem (CMS) is het belangrijk

dat geen ongeautoriseerde toegang kan worden verkregen tot de content/data in dit systeem. Om deze reden

zou de impact van een succesvolle uitvoering van A8, zoals hierboven beschreven is, een erg grote impact

kunnen hebben. Hierdoor kan namelijk ongeautoriseerde toegang worden verkregen tot bepaalde onderdelen

(content) van de applicatie.

Het bestaan van deze standaardkwetsbaarheden vergroot dus de kans dat de applicatie succesvol wordt

aangevallen. Deze kans wordt groter wanneer de bereikbaarheid van webapplicaties ook vergroot wordt.

3.2.2 BEREIKBAARHEID

Doordat webapplicaties gebruik maken van standaardprotocollen en er daarnaast geen speciale software meer

nodig is om de applicatie te gebruiken, is het voor grotere groepen gebruikers mogelijk gebruik te maken van

de webapplicatie. Veel webapplicaties (online bankieren/winkelen) zijn zelfs beschikbaar gemaakt op het

internet, waardoor de applicatie in principe wereldwijd beschikbaar wordt gesteld voor gebruikers.

Door het aantal gebruikers wat de applicatie (potentieel) kan benaderen groter te maken, neemt ook de kans

dat een kwaadwillende gebruiker ongeautoriseerde toegang verkrijgt tot de applicatie en de achterliggende

data toe. Oorzaak hiervan is dat een grotere groep mensen een grotere gemeenschappelijke kennis bezit over

de standaardprotocollen en software waarvan gebruik gemaakt wordt. De bereikbaarheid is dus geen apart

risico, maar het vergroot wederom het kansonderdeel van de risico’s op webapplicaties.

3.3 RISICO’S EN RISICOVERANDERINGEN OP BASIS VAN HET PRAKTIJKONDERZOEK

De risicoveranderingen in deze paragraaf zijn naar voren gekomen tijdens het praktijkonderzoek met zowel

interne IT security professionals als met interne auditors. Op basis van de interviews met de interne auditors

en interne IT security professionals met twee bedrijven zijn verschillende risico’s naar voren gekomen. Doordat

deze risicoveranderingen mogelijk alleen bedrijfsspecifiek zijn, hebben wij deze ter toetsing ook besproken

met een externe IT security professional alsmede een externe auditor. Op deze manier hebben wij de

bedrijfsspecifieke issues weg kunnen halen en alleen de niet bedrijfspecifieke risicoveranderingen in

onderstaande paragrafen weergegeven.

3.3.1 ONTWIKKELPROCES

Een van de onderwerpen die tijdens de gesprekken met verschillende professionals naar voren is gekomen is

het ontwikkelproces omtrent webapplicaties. Voor alle applicaties, zowel traditionele- als webapplicaties dient

beveiliging al tijdens het ontwikkelproces te worden ingebouwd. Het ontwikkelproces dient IT security al

tijdens de eerste fases van een ontwikkeling te behandelen. Dit geldt ook voor het veilig ontwikkelen van

traditionele applicaties.



Tijdens de ontwerp fases van het ontwikkel traject van webapplicaties dient bijvoorbeeld tussen het

Functioneel Ontwerp (FO), waarin de gebruikerseisen worden opgesteld, en het Technisch Ontwerp nog een

extra tussenstap te worden toegevoegd. In deze tussenstap dienen de specifieke eisen vanuit een

beveiligingsoogpunt toe te worden gevoegd aan het technische ontwerp. Alleen zo kan tot een veilig technisch

ontwerp worden gekomen. Een voorbeeld hiervan is de invoervalidatie. Een gebruiker zal voor een bepaald

invoerveld een eis kunnen stellen dat de lengte maximaal 25 karakters mag zijn. Hiernaast moet vanuit een

beveiligingsoogpunt echter worden toegevoegd dat het invoerveld ook geen tekens als ‘, / of < mag bevatten

ter voorkoming van bijvoorbeeld SQL Injection of Cross-site Scripting.

Ondanks het verhoogde risicoprofiel dat is beschreven in paragrafen 3.2.1 en 3.2.2 blijkt onder andere uit het

praktijkonderzoek dat bij de introductie van webapplicaties geen significante veranderingen aan het

ontwikkelproces zijn gemaakt. Ook niet voor bijvoorbeeld de lijsten met kwetsbaarheden zoals de OWASP top-

10.

Hieruit concluderen wij dat, ondersteund door de

praktijkcasus die wij hebben onderzocht, op het gebied

van het ontwikkelen van webapplicaties nog steeds grote

verbeteringen mogelijk zijn om IT security beter te

integreren in het ontwikkel proces. Zoals dit ook is

besproken tijdens de interviews wordt verwacht dat er

extra stappen ondernomen worden in het ontwikkelproces

van webapplicaties. Deze extra stappen hebben wij

beschreven in hoofdstuk 4, waarin we de Secure Software

Development Lifecycle beschrijven.

Daarnaast wordt onderkend dat de opleiding/training en

awareness (bewustzijn ten opzichte van beveiliging) van de

ontwikkelaars verbeterd kan worden. Zeker met het oog

op de standaardkwetsbaarheden (zie paragraaf 3.2.1), lijkt

dit niet in lijn te zijn met het verhoogde risicoprofiel van

webapplicaties. In tegenstelling tot traditionele

applicaties, die vaak beschermd zijn door de perimeter beveiliging van een bedrijf (zowel fysiek als logisch),

komt het bij webapplicaties zeer regelmatig voor dat deze beschikbaar worden gesteld via het internet.

Hierdoor kunnen de fouten die tijdens het ontwikkelproces worden gemaakt grote(re) gevolgen hebben voor

het veiligheidsniveau van de webapplicatie.

Daarnaast zijn tijdens de Dot-com Bubble (die zijn piek had tussen 1998 en 2003) veel bedrijven gestart die

winst wilden maken met het ontwikkelen van webapplicaties en websites. Door deze grote groei zijn veel

mensen gestart met het ontwikkelen van webapplicaties en ontbraken vaak gestructureerde opleidingen of

zijn deze niet gevolgd.

3.3.2 ONDERHOUD

Zowel de interne als de externe IT security experts beschreven echter een extra onderwerp wat van invloed is

op het risicoprofiel van webapplicaties. Mede doordat tijdens de Dot-com Bubble veel nieuwe

applicatieontwikkelaars zijn gestart die geen gestructureerde opleiding hebben gevolgd, worden de

webapplicaties niet gestructureerd ontwikkeld. Dit vergroot de complexiteit en bemoeilijkt de

onderhoudbaarheid van de applicaties. Door het gebrek aan gestructureerde ontwikkeling wordt vaak ook

geen adequate documentatie opgesteld of wordt de broncode van de applicaties niet van het benodigde

commentaar voorzien.

FIGUUR 2 - BEVEILIGING OP ALLE PLAATSEN IN HET

ONTWIKKELPROCES



3.4 CONCLUSIES

In de eerste paragrafen hebben wij beschreven dat wij hebben onderzocht of voor webapplicaties extra risico’s

zijn geïntroduceerd. Zoals in bovenstaande paragrafen duidelijk wordt, hebben webapplicaties niet echte

specifieke risico’s maar wel een ander risicoprofiel dan traditionele applicaties. Door de

standaardkwetsbaarheden, het hanteren van een traditioneel ontwikkelproces voor de ontwikkeling van

webapplicaties en de vergrote bereikbaarheid van webapplicaties, is het kans gedeelte van de risico’s op

webapplicaties vele malen groter. Omdat de kans groter wordt en de impact gelijk blijft, wordt het risico dat

men loopt bij webapplicaties groter (immers, kans maal impact geeft het risico). Hierdoor zijn wij van mening

dat tijdens een IT audit extra controles zouden moeten worden uitgevoerd op webapplicaties, zeker wanneer

deze beschikbaar zijn gesteld op het internet.

Het volgende hoofdstuk beschrijft de maatregelen die bedrijven of IT security professionals kunnen nemen ter

beveiliging van deze applicaties of een controle op de huidige beveiligingsstatus van webapplicaties.



4 BEST PRACTICES VOOR BEVEILIGING IN EEN WEBOMGEVING

In het vorige hoofdstuk is aangegeven dat het risicoprofiel van webapplicaties verschilt ten opzicht van

traditionele applicaties. Bedrijven zien dit ook, waardoor een aantal controls en instrumenten worden ingezet

door IT security en ontwikkelafdelingen. Op basis van de interviews met de IT security professionals van twee

multinationals en een IT Security Subject Matter Expert, zullen in dit hoofdstuk de best practices worden

beschreven. Hierbij wordt beschreven wat de huidige methodieken zijn, waarmee IT security professionals op

dit moment inzicht kunnen krijgen in de beveiligingssituatie van een webapplicatie. Daarnaast worden de

mogelijkheden die gebruikt kunnen worden om het ontwikkelproces te beheersen beschreven in paragraaf

4.4.

FIGUUR 3 - SECURE SOFTWARE DEVELOPMENT LIFECYCLE

Figuur 3 geeft een schematisch overzicht weer van de deelgebieden die belangrijk zijn bij het ontwikkelen van

(web)applicaties. Dit plaatje geeft inzicht hoe de “Secure Software Development Lifecycle” (zie paragraaf 4.4)

zich verhoudt tot andere deelgebieden. Dit betekent dat de andere deelgebieden die hierin worden

weergegeven, ook belangrijk zijn voor de succesvolle implementatie van een (web)applicatie. In de

onderstaande paragrafen zullen we deze gebieden nader toelichten.

4.1 INFRASTRUCTUUR SECURITY

Om applicaties te beschermen tegen ongeautoriseerde toegang kunnen netwerken worden opgedeeld in

verschillende compartimenten, ook kan netwerk verkeer worden gefilterd op specifieke typen netwerkverkeer

of specifieke locaties waarvan het verkeer afkomstig is.

Doordat de bereikbaarheid van webapplicaties vele malen groter is dan traditionele applicaties (zie paragraaf

3.2.2), is dit een goede methode om het verhoogde risico op ongeautoriseerde toegang te verminderen. Deze

methode wordt ook ingezet voor traditionele applicaties die over het netwerk beschikbaar zijn. Een groot

aantal netwerkbeveiliging best practices bestaan, waarin wordt beschreven hoe een netwerk veilig kan

worden ingedeeld. Dit kan bijvoorbeeld worden gedaan via een top down benadering zoals beschreven in het

boek “Top-Down Network Design” [OPP04]. Hierin worden een viertal vaste stappen gevolgd, beginnende

met het verzamelen van de gebruikerseisen. Een ander voorbeeld is het toepassen van de principes zoals

besproken in “Best Practices for network design” from Mark Cooksley [COO07], waarin een set van vaste



maatregelen wordt beschreven. Door dit type controlemaatregelen te implementeren kan de kans op een

succesvolle aanval op een webapplicatie aanzienlijk worden verkleind.

De netwerk indeling reikt van de keuze voor de hardware, de fysieke en logische locatie van routers en

switches in het netwerk, tot de inrichting van firewalls. Ook de aanwezigheid van Intrusion Detection en

Prevention Systems (IDS/IPS) kan hieronder worden verstaan, aangezien deze de kans op een ongemerkte

aanval aanzienlijk beperken.

Bij webapplicaties wordt vaak gebruik gemaakt van een three-tier architectuur. Gewoonlijk wordt deze

architectuur gebruikt bij bijvoorbeeld e-commerce webapplicaties. Hierbij zijn de 3 lagen als volgt opgebouwd:

1. Een presentatie servers met statische inhoud;

2. Een middenlaag die de dynamische inhoud verwerkt . Hierbij wordt vaak gebruik gemaakt van een

programmeertaal als JAVA, ASP.NET of PHP;

3. De back-end database.

Deze indeling moet op een adequate manier zijn gescheiden in een netwerk. Zo zal de database op een intern

systeem geplaatst moeten zijn, omdat deze niet vanaf het internet moet kunnen worden benaderd. De

presentatie server moet juist wel benaderd kunnen worden en zal daarom in een DMZ geplaatst worden.

Om de inrichting van het netwerk te onderzoeken wordt vaak een netwerk scanner

ingezet. Uit het praktijkonderzoek en uit onze ervaringen met netwerk scanning, is

gebleken dat binnen bedrijven vaak onduidelijkheden bestaan over welke webapplicaties

nu waar worden ingezet en voor wie deze benaderbaar zijn. Ook zien wij in de praktijk dat

bij de installatie van nieuwe servers onnodig en onbedoeld een standaard

beheer/management pagina geïnstalleerd wordt, welke kan worden gebruikt om op afstand beheer uit te

voeren op de server. Deze pagina is vervolgens beschikbaar voor het hele bedrijf of zelfs via het internet en

kan worden gebruikt met een standaard gebruikersnaam en wachtwoord.

Om applicaties, zowel intern als extern, te detecteren kunnen netwerk scans worden ingezet. Door servers op

het netwerk te scannen met tooling (zoals NMAP [NMA10] of Nessus [TNA10]) die webapplicaties of

webservers detecteren, kan het server landschap in kaart worden gebracht en kunnen configuratiefouten in de

webservers worden ontdekt. Op basis van het serverlandschap is het mogelijk te identificeren welke

applicaties zowel via het interne netwerk (intranet) als het externe netwerk zijn te benaderen. Dit is dezelfde

aanpak die een aanvaller kan kiezen om het netwerk te verkennen.

Door het serverlandschap in kaart te brengen kunnen de beschikbare webservers worden geanalyseerd op nut

(tegen het risico van kwetsbare voorbeeld webapplicaties) , legitimiteit (bijvoorbeeld applicaties in

ontwikkeling die voor iedereen beschikbaar zijn) en kwetsbare versies (verouderde webapplicaties).

Dit instrument kan ook worden gebruikt om traditionele applicaties te detecteren en te identificeren, echter is

het vele malen effectiever voor het identificeren van webapplicaties. Dit komt doordat de

standaardprotocollen (zie paragraaf 3.2.1) die door webapplicaties worden gebruikt eenvoudiger

geautomatiseerd geïdentificeerd, geanalyseerd en getest kunnen worden.

4.2 APPLICATIE SECURITY

Een andere methode (om inzicht te krijgen in de beveiligingssituatie van een webapplicatie) die wordt ingezet

door IT security afdelingen is een penetratie test. Hierbij worden ethical hackers of interne IT security

professionals ingezet om zo veel mogelijk kwetsbaarheden in de beveiliging van webapplicaties te vinden. Dit

wordt gedaan door proberen in te breken op dezelfde manier als een interne of externe aanvaller dat zou



doen. Aangezien een groot aantal standaard aanvallen beschikbaar is voor webapplicaties is het mogelijk op

een aantal standaard methodieken te testen (zie de OWASP top 10 in paragraaf 3.2.1). Ook is tooling, zoals

bijvoorbeeld Nikto [SUL08] of Paros proxy [CTC04], beschikbaar die standaard zwakheden binnen applicaties

kan detecteren.

Door deze standaardaanvallen is het eenvoudiger voor aanvallers om kwetsbaarheden in de applicaties te

vinden, maar ook eenvoudiger voor ontwikkelaars en beheerders om deze beveiligingslekken op te sporen en

eventueel op te lossen. Het uitvoeren van een penetratie test helpt hierbij om zo veel mogelijk IT security

zwakheden te identificeren en te mitigeren.

Een van de eigenschappen van een penetratie test is, dat de resultaten zeer afhankelijk zijn van de tijd die

wordt besteed aan het onderzoeken van de applicatie, maar ook dat bijna dagelijks nieuwe zwakheden

worden geïdentificeerd (op het internet). Hierdoor is het zeer complex een inschatting te maken over de

kwaliteit van een applicatie, zelfs nadat een penetratietest is uitgevoerd. Doordat de kans dat een aanvaller

verdere beveiligingsfouten in de webapplicatie ontdekt zeer lastig in te schatten valt, is het zeer complex hier

een zinvolle risicowaardering op te maken. Desalniettemin is het raadzaam deze testen uit te voeren, omdat

hiermee zeker belangrijke kwetsbaarheden binnen de applicaties geïdentificeerd kunnen worden. Door deze

testen periodiek uit te voeren zullen steeds meer kwetsbaarheden gevonden en uiteindelijk voorkomen

kunnen worden, waardoor de kwaliteit van de applicatie verbeterd wordt en de kans kleiner dat een aanvaller

een succesvolle aanval uit kan voeren.

4.3 CONFIGURATIE SECURITY

Ook de software die een webapplicatie beschikbaar maakt voor gebruikers zal beveiligd moeten worden. Daar

waar de laag onder een traditionele applicatie vaak het besturingssysteem is, is dit bij een webapplicatie een

webserver. Hierdoor is de beveiliging van een webapplicatie afhankelijk van de beveiliging van de webserver,

zoals een traditionele applicatie afhankelijk is van de beveiliging van een besturingssysteem. Een belangrijke

stap bij het implementeren van een webapplicatie is om ook de webserver goed te configureren. Door een

configuratie review uit te voeren op de instellingen van een webserver, kan een IT Security professional beter

controle houden over de beveiliging van de omgeving van een webapplicatie. Net als bij traditionele

applicaties zal ook aandacht moeten worden besteed aan de lagen onder de webserver, zoals de configuratie

van het besturingssysteem.

Een voorbeeld van een controle die hierbij uitgevoerd kan worden is het nagaan welke bestanden zichtbaar

zijn voor een gebruiker van de webapplicatie. Dit kan onder andere worden gedaan door het opvragen en

beoordelen van een directory listing. Hierdoor kan op een efficiënte manier worden gecontroleerd of geen

bestanden worden aangeboden die niet online beschikbaar zou moeten zijn, zoals een backup van alle data of

de broncode van de webapplicatie. Deze bestanden zullen waarschijnlijk niet gevonden worden door middel

van een netwerk scan of een applicatie test, omdat de bestanden vaak webapplicatie specifiek zijn.

4.4 SECURE SOFTWARE DEVELOPMENT

Een logisch gevolg van de lijst met standaard aanvallen is dat tegelijkertijd een lijst met veel voorkomende

ontwikkelfouten uit het OWASP project (zie paragraaf 3.2.1) wordt gepubliceerd. Deze kunnen worden

gebruikt om software ontwikkelaars te helpen bij het vermijden van deze fouten en daardoor het verminderen

van de kwetsbaarheden in webapplicaties, door IT security in het gehele ontwikkelproces te benadrukken (zie

ook 3.3.1).

Het minimaliseren van IT security gerelateerde fouten in software kan worden gedaan door een Secure

Software Development Lifecycle (SSDLC) te introduceren. Deze methodiek is niet gelimiteerd tot

webapplicaties, maar kan zeker structuur in het ontwikkelproces brengen, waarin de beveiliging niet



onderbelicht blijft. In een SSDLC wordt de IT security tijdens het gehele ontwikkeltraject benadrukt. Daarnaast

kan een gestructureerde manier van programmeren de complexiteit van de webapplicaties verkleinen,

waardoor het onderhoud eenvoudiger zal zijn. Om te zorgen voor de ontwikkeling van veilige applicatie code,

moet beveiliging deel uitmaken binnen alle fasen in het ontwikkelproces. Dit geldt zowel voor een lineair

proces als de watervalmethode of een iteratief proces als Rational Unified Process (RUP). Ondanks dat dit ook

van toepassing is op traditionele applicaties, is het extra belangrijk op webapplicaties vanwege het afwijkende

risicoprofiel. In de onderstaande paragrafen hebben wij getracht (met behulp van input uit het

praktijkonderzoek) extra stappen te definiëren die in het ontwikkelproces speciaal voor webapplicaties

ondernomen moeten worden.

Tijdens de ontwerpfase moeten naast de gebruikerseisen ook technische (security) eisen worden opgenomen

ter voorkoming van de zwakheden in de beveiliging van (web)applicaties. Hierbij kan worden gedacht aan

eisen die SQL Injection of Cross-site Scripting (XSS) aanvallen onmogelijk moeten maken. Zo zou voor

invoervalidatie niet alleen de functionele eisen (als veld mag maximaal 40 karakters bevatten) moeten worden

uitgeschreven, maar ook technische eisen (als een veld mag geen ‘ of < tekens bevatten).

Voor de ontwikkelfase is het van belang dat ontwikkelaars op de hoogte zijn van bijvoorbeeld de OWASP Top-

10 en hier ook specifieke maatregelen voor nemen. Dit kan worden gedaan door adequate trainingen voor de

ontwikkelaars, awareness creëren onder de ontwikkelaars en/of tijdens de ontwikkeling al peer reviews uit te

voeren. Een van de maatregelen die tijdens de interviews werd benadrukt is het gebruik van automatische

tooling om gemakkelijk herkenbare kwetsbaarheden te identificeren en te voorkomen. Ook de resultaten van

penetratietesten of code-reviews kunnen met ontwikkelaars worden besproken, zodat deze kwetsbaarheden

minder snel zullen terugkeren.

Tijdens de testen implementatiefase dient specifiek aandacht te zijn voor de kwetsbaarheden die in de

webapplicatie kunnen zitten. Naast gebruikers- of acceptatietesten kunnen specialisten technische security

testen uitvoeren op de webapplicatie (dit kan eventueel ook door externe specialisten worden uitgevoerd)

voordat de applicatie in productie wordt genomen.

Ook na de ontwikkeling van een applicatie zal voldoende aandacht moeten worden besteed om IT security

fouten die worden ontdekt recht te zetten (te patchen). Met name in het geval van webapplicaties, waarbij

fouten eerder worden ontdekt door de vergrote bereikbaarheid en kennis van de gebruikte technologieën, zal

het adequaat reageren op IT security problemen zeer belangrijk zijn. Dit geldt ook (met name) wanneer de

web applicatie “live” is.

Door tijdens de SSDLC best practices voor de relevante technieken te introduceren wordt op een

gestandaardiseerde manier naar relevante risico’s gekeken. Onder deze best practices valt uiteraard de

OWASP top 10, maar ook documenten zoals het Web application Security Frame van Microsoft [MEI05]

kunnen worden gebruikt om risico’s die specifiek gelden voor de gebruikte technieken te onderkennen.

4.5 SOURCE CODE SECURITY

Een methodiek die vaak in combinatie met een penetratietest of samen met de SSDLC wordt geïntroduceerd,

is een code review. Een code reviews is een methode om onafhankelijk van de ontwikkelaar de broncode van

een programma te beoordelen om op deze manier mogelijke beveiligingsfouten te ontdekken. Deze techniek

wordt ook toegepast bij traditionele applicaties, maar kunnen bij webapplicaties gemakkelijker worden

uitgevoerd. Dit komt onder andere doordat bij webapplicaties veel gebruik gemaakt wordt van veel gebruikte

en makkelijk leesbare programmeer- of scriptingtalen. Hierdoor zal het (zeker in de huidige tijd) gemakkelijker

zijn een expert te vinden die de code review uit kan voeren.



Een code review kan op verschillende manieren worden uitgevoerd. Zo kan deze geautomatiseerd door een

software tool worden uitgevoerd en kunnen daarmee een aantal van de standaardkwetsbaarheden zoals die in

paragraaf 3.2.1 zijn beschreven, gedetecteerd worden. Deze zal een aantal eenvoudig te detecteren fouten

kunnen identificeren en is zeer kostenefficiënt, maar zal lang niet alle fouten eruit halen. Voor meer

diepgaande review, kan de code manueel beoordeeld worden door een expert (anders dan de ontwikkelaar)

om zo ook niet-standaard en lastiger te detecteren fouten trachten te ontdekken in de broncode.

Aangezien een aantal van de standaardfouten die vaak in webapplicaties worden aangetroffen (zie de OWASP

top 10 in paragraaf 3.2.1) ook door geautomatiseerde tools zijn te ontdekken, is dit een methode die

vergeleken met traditionele applicaties relatief efficiënt kan worden ingezet.



5 DE IT-AUDITOR EN WEBAPPLICATIES

Tijdens een IT audit wordt vaak vanuit een de risicoperspectief naar applicaties gekeken, maar het is ook

mogelijk om een control based approach te kiezen als controleaanpak. In dit hoofdstuk zal worden beschreven

wat de huidige audit methodieken zijn die worden toegepast tijdens het beoordelen van een traditionele

applicatie. Daarnaast zullen wij de gebreken van deze methodiek beschrijven voor het beoordelen van

webapplicaties om vervolgens in hoofdstuk 6 met een oplossing voor dit probleem te kunnen komen.

5.1 AUDIT AANPAK

Uit discussies tijdens het praktijkonderzoek met zowel de interne als de externe IT auditors is gebleken dat de

audit approach van bedrijven (zowel de interne als externe audit aanpak) de laatste jaren weinig veranderd is.

Voordat wordt gestart met een audit zal eerst het normenkader moeten worden vastgesteld. Dit normenkader

wordt doorgaans opgesteld aan de hand van best practices of control frameworks. Zo zal een audit waarvan

het normenkader is gebaseerd op de ISO27001 standaard een risk based approach hebben. Een andere

methodiek is de meer control gerichte audit (rule based) die gebaseerd is op weten regelgeving.

De risk based approach stelt dat alleen controls geïmplementeerd moeten zijn welke het risico op de onjuiste

werking van de applicatie en de processen hieromheen minimaliseren. Op deze manier worden alleen de

relevante controls geaudit en zullen controls die minder grote risico’s afdekken niet worden meegenomen in

de scope van de audit. Bij deze risk based approach kan gebruik worden gemaakt van standaard lijsten met

risico-control koppelingen, zoals bijvoorbeeld PD3005:2002 Guide on the selection of BS 7799 Part 22 controls

[BSI02] om er voor te zorgen dat deze wordt gebaseerd op een lijst met veel voorkomende risico’s.

Deze lijsten, zoals de PD3005, met risico-control koppelingen zijn de laatste jaren niet wezenlijk veranderd. Zo

is bovenstaand voorbeeld, PD3005, gepubliceerd in december 2002 en sindsdien niet meer aangepast voor

nieuwe ontwikkelingen. Ook weten regelgeving is niet erg flexibel en gaat niet snel met de tijd mee. Normaal

gesproken is dit geen groot probleem, aangezien de genoemde standaarden niet heel gedetailleerd zijn en

meer focussen op de principes achter de technieken. Aangezien de principes niet of nauwelijks veranderen is

dit een hele goede basis voor de meeste audits.

Doordat webapplicaties een aantal unieke eigenschappen hebben (zoals besproken in hoofdstuk 3),

verschuiven de risico’s bij webapplicaties ten opzichte van traditionele applicaties. Wij zijn van mening dat de

methodieken, zoals penetratietesten en code-reviews, die nu alleen vanuit een beveiligingsoogpunt worden

ingezet, van grote toegevoegde waarde kunnen zijn op de uitvoer audits op webapplicaties. Hierbij hebben wij

onderzocht of oplossingen bestaan, die van deze technieken gebruik maken, om zo het specifieke risicoprofiel

van webapplicaties te behandelen.

5.2 BESTAANDE OPLOSSINGEN

Wanneer in literatuur gezocht wordt naar standaard normenkaders of aanpakken speciaal voor webapplicaties

blijkt dat hier geen open standaarden of specifieke oplossingen gegeven worden, die specifiek ingaan op het

risicoprofiel van webapplicaties. In een document van het SANS technologie instituut [ULL07] is een oplossing

gegeven voor een zeer beperkte audit die in een Quick Scan een inzicht moet geven in de veiligheid omtrent

een webapplicatie.

2 BS 7799 part 2 is tegenwoordig beter bekend als ISO27001.



Deze audit approach is echter niet compleet en zal geen redelijke mate van zekerheid geven over de

betrouwbaarheid van een webapplicatie. Het toont alleen een beperkte set van beveiligingsfouten aan die

mogelijk in een webapplicatie kunnen zitten (waarbij slechts een beperkte set van de OWASP top 10

kwetsbaarheden wordt onderzocht).

5.3 PRAKTIJK

Tijdens het praktijkonderzoek is besproken met de verschillende geïnterviewde personen of in de huidige audit

aanpakken van applicaties specifiek naar de best practices, zoals beschreven in hoofdstuk 4, wordt gekeken.

Hierbij werd, door zowel de externe als de interne medewerkers, aangegeven dat deze methoden steeds vaker

worden toegepast, maar zeker (nog) geen standaard middel zijn. Ook komt het regelmatig voor dat na een

penetratietest de bevindingen niet adequaat worden opgevolgd en dat dit ook tijdens de audit niet naar voren

komt, waardoor bekende zwakheden in een applicatie gewoon blijven bestaan.

De change- en ontwikkelprocessen van applicaties worden vaak wel meegenomen tijdens een IT audit. Hierbij

wordt met name beoordeeld dat tijdens de processen de juiste approvals zijn gegeven en of bij het uitvoeren

en implementeren van de wijziging de beveiliging van de webapplicatie is meegenomen. Echter wordt

doorgaans niet gekeken naar de specifieke ontwerpen die worden opgesteld of tests die door de ontwikkelaars

of externe partijen worden uitgevoerd voor bijvoorbeeld standaardkwetsbaarheden als de OWASP top 10.

Hoofdstuk 6 zal een aanpak beschrijven die kan worden gebruikt om een oordeel te geven op de betrouwbare

werking van webapplicaties, waarbij rekening wordt gehouden met het veranderde risicoprofiel die in deze

Web 2.0 wereld is ontstaan.



6 ADVIES

In de vorige hoofdstukken is, op basis van het praktijkonderzoek en eigen ervaringen, naar voren gekomen dat

webapplicaties een ander risicoprofiel hebben dan traditionele applicaties. Om deze reden zullen door de IT

auditors extra controles moeten worden uitgevoerd. In het vorige hoofdstuk hebben wij beschreven dat de

audit aanpak de laatste jaren echter niet is veranderd en ontoereikend is voor de beoordeling van

webapplicaties. Hoofdstuk 4 beschrijft methoden die door IT security professionals gebruikt worden voor een

beoordeling van webapplicaties. Wij denken dat deze methoden door IT auditors beoordeeld of gebruikt

kunnen worden om mede hierop gebaseerd, een oordeel te geven over de juistheid en volledigheid van de

dataverwerking door webapplicaties.

In de onderstaande tabel hebben wij een aantal maatregelen weergegeven die de bedrijven zelf zouden

moeten uitvoeren, of laten uitvoeren door een derde partij, om meer inzicht te krijgen over de juiste

beveiliging van webapplicatie. Door de resultaten van deze maatregelen mee te nemen in het audit proces ,

kan de mate van beheersing van de kwetsbaarheden in de webapplicatie beter worden beoordeeld. Uit het

praktijkonderzoek is gebleken dat deze maatregelen maar zelden (zeker in een combinatie van de

onderstaande maatregelen) worden getest tijdens een IT audit.

TABEL 2 - IT AUDIT MAATREGELEN

Onderwerp Werkzaamheden

Beveiligingstesten

(netwerk en

penetratietesten) –

Rapportage

Beveiligingstesten als netwerkscanning, netwerkindeling, penetratietesten en code

review kunnen een inzicht geven in de beveiligingssituatie van een webapplicatie. Deze

beveiligingstesten zouden in beginsel niet door de auditor zelf worden uitgevoerd, dit

zou immers een grote last zijn op de werkzaamheden. De uitvoering van deze

werkzaamheden is primair een verantwoordelijkheid van de organisatie. De rapportage

van deze testen kan echter wel beoordeeld worden tijdens de uitvoering van een audit.

Bij de beoordeling van een rapportage van een beveiligingstest kunnen bijvoorbeeld de

volgende onderdelen gecontroleerd worden:

- Wat zijn de geïdentificeerde kwetsbaarheden met een hoog risico?

- Wat was de precieze scope van de beveiligingstest?

- Welke werkzaamheden zijn uitgevoerd (alleen tests vanuit het perspectief van

een ongeautoriseerde gebruiker of ook vanuit het perspectief van een

geautoriseerde gebruiker)?

- Is specifiek gekeken naar standaardkwetsbaarheden als de OWASP top-10?

- Zijn er specifieke werkzaamheden uitgevoerd voor het testen van de business

logica van de betreffende webapplicatie (bijvoorbeeld het overboeken van geld

door een bankierapplicatie).

- Welke technieken zijn toegepast voor het testen van de webapplicatie?

Beveiligingstesten

– Opvolging

Niet alleen de geconstateerde kwetsbaarheden kunnen tijdens audits worden bekeken

maar ook de uitgevoerde acties naar aanleiding van de beveiligingstesten zijn van

belang. De kwetsbaarheden moeten op basis van het risico en een kosten/baten

analyse beoordeeld worden door de IT specialist in samenwerking met de eigenaar.

Naar aanleiding van die beoordeling dienen maatregelen genomen te worden, of

aanpassingen gemaakt te worden in de applicatie. De maatregelen die genomen zijn en

het proces van de totstandkoming van deze maatregelen kunnen door de IT auditor

worden beoordeeld.



Onderwerp Werkzaamheden

Ontwikkelmethode De ontwikkelmethode die gebruikt wordt kan worden beoordeeld. Het ontwerpen,

ontwikkelen, maar ook de veranderingen of toevoegingen aan de applicaties dienen

volgens een standaardproces te worden uitgevoerd. In elk van de fases van dit proces

dient de beveiliging van de applicatie te worden meegenomen. Dit geldt echter ook

voor traditionele applicaties.

Specifiek voor webapplicaties moeten tijdens de ontwikkelfases echter extra

beveiligingsmaatregelen genomen worden, zoals in hoofdstuk 4 is beschreven. Hierin is

beschreven dat zaken als bijvoorbeeld de OWASP top-10 dienen te worden behandeld

in het ontwikkelproces om deze standaardfouten te vermijden. De testen die worden

uitgevoerd voor webapplicaties dienen hierop te worden afgestemd. Op deze manier

zijn niet alleen correctieve maatregelen, maar ook preventieve maatregelen ingericht in

het proces ter voorkoming van de kwetsbaarheden.

Inrichting Het veiligheidsniveau van een applicatie wordt mede bepaald door de veiligheid van de

omgeving waarin de applicatie zich bevindt. Dit impliceert dat veiligheidsmaatregelen

moeten worden genomen op elke laag van de applicatieomgeving. Gezien het

risicoprofiel van webapplicaties zijn de onderstaande maatregelen bij een webapplicatie

extra belangrijk. Al zijn deze (deels) ook van toepassing op een traditionele applicatie.

Netwerkinfrastructuur: De netwerkinfrastructuur kan ondersteunend werken voor de

veiligheid van applicaties. De infrastructuur kan deze bijdrage leveren door bijvoorbeeld

zonering, gelaagdheid of scheiding van de verkeersstromen in te stellen. Zeker in

verband met een three-tier architectuur, zoals in hoofdstuk 4.1 is beschreven. Doordat

webservers beschikbaar worden gesteld op het internet is bijvoorbeeld een firewall ook

een belangrijk beveiligingsinstrument.

Configuratie: Veilige configuratie van besturingssystemen en software van derden van

de webapplicatie. Omdat er maar een beperkte hoeveelheid webservers gebruikt wordt

door een grote gebruikersgroep (zie ook FIGUUR 4), zullen kwetsbaarheden in deze

webservers sneller bekend worden. Door de grotere bereikbaarheid zullen deze ook

sneller misbruikt kunnen worden en komen er eerder automatische tools beschikbaar,

welke deze kwetsbaarheden kunnen misbruiken. Hetzelfde geldt voor kwetsbaarheden

in het besturingssysteem.

Applicatie: Veilige configuratie van de applicatie software, bijv. verwijderen van

onnodige functionaliteit of administratieve interfaces. Wanneer deze administratieve

interfaces beschikbaar zijn op het internet, kunnen deze een ingang zijn voor aanvallers.

Zo kunnen zwakheden in deze interfaces de beveiliging van de webapplicatie en de

webserver ondermijnen.

Broncode: Veilige implementatie van functies, sessiebeheer en invoercontroles.

Daarnaast ook de beveiliging van de broncode zelf. Omdat deze bij webapplicaties niet

gecompileerd zal worden en direct door de applicatie wordt gebruikt, is deze altijd op

de server aanwezig. De toegang tot deze leesbare code dient te worden beveiligd.

Naast de directe beveiliging van een product en de omgeving hiervan, dienen ook in de

processen en organisatorische aspecten voor het ontwikkelen van applicaties

beveiliging mee genomen te worden.



6.1 BEOORDELING BEVEILIGINGSTESTEN

Indien de bovenstaande rapportages en informatie uit de beveiligingstesten niet beschikbaar zijn voor de

auditor, is de mogelijkheid nog aanwezig dat de auditor, al dan niet met inschakeling van een expert, een

(beperkte) beveiligingstest uitvoert. Afhankelijk van het risicoprofiel zal de noodzaak en scope van deze

beveiligingstest bepaald moeten worden. Daarnaast bestaat de mogelijkheid dat een auditor de onderwerpen

uit tabel 2 alsnog door de beheerder uit laat voeren.

In dit geval en in het geval van de (beperkte) beveiligingstest zijn wij van mening dat minimaal op bepaalde

standaardfouten moet worden gecontroleerd voor de beveiligingstesten. Door een (beperkte) set van

standaardfouten te selecteren en hiervoor te testen tijdens een IT audit, denken wij een efficiënte balans te

kunnen vinden tussen de diepgang van de audit en het budget dat hiervoor uitgetrokken wordt. Net zoals elk

framework en elke best practice, zal deze aanpak moeten worden aangepast naar de specifieke situatie van de

audit. Wij zijn van mening dat er op een efficiënte wijze meer zekerheid over de juiste werking van een

webapplicatie kan worden verkregen, door de volgende onderwerpen te onderzoeken gedurende de audit

indien deze van toepassing zijn voor deze specifieke applicatie:

• Invoercontrole (OWASP Top 10 nummer 1 en 2)

Verschillende standaardkwetsbaarheden kunnen in webapplicaties worden afgevangen met een

adequate manier van invoercontrole. Zo kan men SQL injection en XSS voorkomen door de invoer die

gebruikers kunnen ingeven in de webapplicaties te filteren op vreemde tekens (bijvoorbeeld <, ‘ of #).

Bij beveiligingstesten worden die kwetsbaarheden vaak gedetecteerd (mede doordat deze

kwetsbaarheden door automatische tooling zoals Paros kunnen worden opgespoord).

Als alternatief kan geïnformeerd (en gecontroleerd) worden hoe de applicatie de invoercontrole

uitvoert. Wanneer de invoer controle voor elk veld apart moet worden aangezet en toegepast is de

kans aanwezig dat dit niet voor alle invoervelden is geïmplementeerd. Een oplossing om dit te

implementeren is generieke regels te schrijven die met reguliere expressies de invoer van gebruikers

filteren. Deze reguliere expressies dienen hierbij niet alleen controles uit te voeren op de eisen die

worden gesteld door de business, bijvoorbeeld lengte van het invoerveld is maximaal 25 karakters.

Hierbij moeten ook de technische controles worden gedaan, zoals hierboven beschreven.

• Fouten in de authenticatie en het sessiebeheer (OWASP Top 10 nummer 3, 8 en 10)

De authenticatie is een belangrijk onderdeel van alle applicaties die voorkomt dat ongeautoriseerde

toegang wordt verkregen tot de applicatie. Dit is een onderwerp dat bij de meeste applicatie audits

wel wordt beoordeeld. Doordat webapplicaties beschikbaar zijn op het internet, zal deze

authenticatie strikter moeten worden geïmplementeerd. Op het internet kunnen talloze

kwaadwillende personen namelijk aanvallen uitvoeren op deze authenticatie (bijvoorbeeld brute-

force aanvallen).

.Het is belangrijk dat voor een dergelijke sessie beveiligingsmaatregelen zijn genomen ter voorkoming

dat deze kunnen worden misbruikt of herbruikt door aanvallers. Voor ieder onderdeel (dus iedere

URL) die te benaderen is door gebruikers dient een controle plaats te vinden of een sessie is

aangemaakt voor de gebruiker en of deze gebruiker ook toegang heeft tot dit applicatieonderdeel.

Daarnaast dienen sessies tijdig worden afgesloten ter voorkoming van het herbruiken of uitwisselen

van de sessievariabelen, indien deze kunnen worden verkregen door een aanvaller.

• Configuratie fouten in de beveiliging van de webserver/webapplicatie (OWASP Top 10 nummer 6)



Een foutieve configuratie van de webserver of webapplicatie kan zorgen voor verschillende

kwetsbaarheden, dit geldt voor elke configuratiefout. Een voorbeeld hiervan is, dat een

ongeautoriseerde gebruiker een lijst kan opvragen van alle bestanden die via de webserver

beschikbaar zijn (binnen een directory). Omdat webapplicaties beschikbaar worden gesteld op het

internet zullen configuratiefouten eerder misbruikt worden door kwaadwillenden. Daarnaast worden

er wereldwijd maar een beperkte hoeveelheid webservers gebruikt, zoals onderstaand figuur laat

zien. Hierin wordt aangetoond dat in 2010 wereldwijd het gebruik bijna evenredig verdeeld is tussen

de webservers van Apache en Microsoft. Wereldwijd is er dus veel kennis van deze producten. Om

deze reden zullen configuratiefouten snel misbruikt kunnen worden. Daarnaast is er speciale tooling

ontwikkeld die juist de configuratiefouten van deze webservers kan vinden, bijvoorbeeld Nikto3.

FIGUUR 4 - VERDELING VAN HET GEBRUIK VAN WEBSERVERS TUSSEN 1995 EN 20104

• Onvoldoende transportbeveiliging (OWASP Top 10 nummer 9)

De gegevens van en naar een webapplicatie worden verstuurd via het HTTP protocol. Dit protocol is

een zogenaamd ‘clear-text’ protocol. Dit wil zeggen dat de gegevens die tussen de client en de server

worden verstuurd in principe niet versleuteld zijn. Een ieder die deze gegevens kan benaderen, door

bijvoorbeeld sniffing, kan deze ook inzien. Zo ook gebruikersnaam en wachtwoord combinaties of

andere gevoelige gegevens. Om deze reden dienen maatregelen genomen te worden. Een

standaardoplossing is het gebruik van het HTTPS protocol, welke de gegevens die verzonden worden

op een veilige manier kan versleutelen (mits juist geconfigureerd). Zeker voor webapplicaties die

beschikbaar worden gemaakt op het internet is dit van belang, omdat de toegang tot de eventueel

onversleutelde gegevens vele malen groter is, dan wanneer een applicatie alleen beschikbaar wordt

gemaakt op het interne netwerk. Om deze reden dient HTTPS te zijn geïmplementeerd voor alle

pagina’s waar bij gevoelige informatie verstuurd wordt tussen de client en de server.

Zoals eerder is benoemd zullen bedrijven een set van controle maatregelen uitvoeren en naar aanleiding van

de scope van een audit zullen deze wel of niet beoordeeld worden. Dit geldt ook voor de maatregelen die

genomen zijn voor webapplicaties. Daarnaast zijn wij van mening dat een auditor voor de uitvoering van deze

controles een minimaal kennis niveau van webapplicaties dient te bezitten. Dit is natuurlijk ook het geval

3 Zie ook http://cirt.net/

4 Bron: http://news.netcraft.com/archives/2010/01/



wanneer een audit wordt uitgevoerd op een Windows, AS/400 of UNIX platform. Om deze reden zou een

training en een uitgewerkt normenkader kunnen worden opgesteld. Dit normenkader zou dan gedetailleerde

informatie kunnen bevatten over de mogelijke oplossingen die voor bijvoorbeeld de invoercontrole gekozen

kunnen zijn (zie hiervoor ook het hoofdstuk vervolgonderzoek in hoofdstuk 7).

6.2 MATE VAN ZEKERHEID

De grootste uitdaging die we hierbij hebben is het kwantificeren van de extra waarde die deze maatregelen

toevoegen of de zekerheid die kan worden verkregen.

Bij de beoordeling van het ontwikkelproces of de rapportage kan geen absolute zekerheid verkregen worden

dat geen kwetsbaarheden meer aanwezig zijn in de webapplicaties. Doordat webapplicaties steeds

vernieuwen en bijna dagelijks nieuwe kwetsbaarheden ontstaan, is het zeer moeilijk de kans op

beveiligingsfouten in de webapplicatie en de impact van deze fouten te kwantificeren. Bijvoorbeeld een

penetratietest op een webapplicatie geeft inzicht in de kwetsbaarheden die tot de datum van uitvoering

bekend waren en in de tijd die voor de test stond gevonden konden worden. De penetratietesten laten alleen

die kwetsbaarheden zien, die zijn gevonden tijdens de uitvoer. De testen geven geen zekerheid dat de

kwetsbaarheden niet gevonden of aanwezig zijn. Om deze reden zullen deze testen dus periodiek moeten

worden uitgevoerd door bedrijven. Daarnaast is het aan te bevelen verschillende personen de applicaties uit te

laten voeren en eventueel externe partijen in te huren die de beveiligingstesten uitvoeren. Bij het gebruik van

externe partijen raden wij ook aan om bijvoorbeeld om de twee jaar van derde partij te wisselen, doordat ook

de derde partijen op een bepaald moment een ‘blindheid’ krijgen voor de kwetsbaarheden in de applicaties

(een vorm van bedrijfsblindheid).

Wij zijn van mening dat het periodiek uitvoeren van de beveiligingstesten die genoemd zijn in tabel 2, de

kansen die de risico’s bij webapplicaties vergroten (zoals besproken in hoofdstuk 3), kunnen verkleinen.

Daardoor kunnen de aanvullende risico’s die in hoofdstuk 3 zijn geïdentificeerd voor webapplicaties ten

opzichte van traditionele applicaties worden gemitigeerd. Alleen dan kan er met redelijke mate van zekerheid

geconcludeerd worden dat de maatregelen die genomen zijn, voldoende mitigerend zijn.

Door deze aanpak te kiezen is het mogelijk de auditaanpak beter op webapplicaties aan te laten sluiten. In

principe is het auditonderdeel waarin de webapplicatie wordt bekeken te vergelijken met de manier waarop

op dit moment vaak naar een besturingssysteem of de netwerkinfrastructuur wordt gekeken:

Op het moment dat er een UNIX omgeving aanwezig is waarop applicaties zijn geïnstalleerd die in scope zijn

voor een audit, zal over het algemeen een aantal UNIX specifieke controles op deze systemen worden

uitgevoerd. Door op dezelfde manier een selectie van de hierboven genoemde controles uit te voeren als er

een webapplicatie in scope is, zal dit de juiste balans creëren tussen de risico’s en de efficiëntie van de audit.



7 CONCLUSIE

In de vorige hoofdstukken zijn verschillende onderwerpen met betrekking tot webapplicaties besproken. In dit

laatste hoofdstuk zullen de verschillende onderwerpen aan elkaar geknoopt worden tot de eindconclusie van

deze scriptie. Hiermee kan de hoofdvraag van dit onderzoek worden beantwoord.

7.1 CONCLUSIE

In het begin van dit document zijn de hoofd- en subvragen van dit onderzoek opgesteld. Hieronder zullen wij

per (sub)vraag antwoord en toelichting geven op de uitwerkingen van deze vragen eerder in dit document.

Wat zijn de huidige trends t.a.v. webapplicaties?

In hoofdstuk 2 van dit document is besproken dat bedrijven steeds vaker gebruik gaan maken van op web

gebaseerde applicaties. Zeker met trends als Software as a Service (SaaS) en Cloud Computing zal meer en

meer van webapplicaties gebruik gemaakt worden. De voordelen van webapplicaties als de vergrote

bereikbaarheid maakt dat bedrijven gebruik willen maken van deze nieuwe technieken.

Welke (informatiebeveiligings)risico’s bestaan bij het gebruik van webapplicaties?

Tijdens het praktijkonderzoek is met twee verschillende bedrijven gesproken over de webapplicaties die zij

hebben ingericht in hun organisaties. Daarnaast is met de bedrijven de risico’s besproken die zij identificeren.

Deze uitkomsten zijn geverifieerd met 2 personen die buiten de organisatie staan, maar bij veel verschillende

organisaties IT security onderzoek of audits doen. Dit is uitgewerkt in hoofdstuk 3 van dit document. Hieruit is

naar voren gekomen dat er een aantal afwijkingen gelden voor webapplicaties ten opzichte van het

risicoprofiel van traditionele applicaties:

• Het gebruik van standaardprotocollen, waaronder het gebruik van scripting talen; dit is een van de

oorzaken (naast het grotere gebruik, dus kennis, en beschikbaarheid van deze protocollen); dat

publiekelijk beschikbare lijsten bestaan die veel voorkomende fouten bij de implementatie van

webapplicaties beschrijven;

• Grotere bereikbaarheid; doordat de applicatie makkelijker te benaderen is met standaard software,

waardoor meer aanvallers de applicatie ook kunnen benaderen;

• Door de snelle groei van webapplicaties in de internetbubbel van 1998 tot 2003 zijn veel mensen en

bedrijven webapplicaties gaan ontwikkelen. Door deze snelle groei missen veel ontwikkelaars

structurele kennis en veel bedrijven structurele ontwikkelmethodes voor het ontwikkelen van

webapplicaties, zoals een veilig ontwikkelproces (SSDLC);

• Webapplicaties worden vaak (ook als gevolg van het hierboven genoemde risico) relatief complex

gemaakt (dit kan om bovengenoemde redenen ook onnodig zijn). Hierdoor neemt ook de

complexiteit van de architectuur toe, waardoor het onderhouden van de server kant van de applicatie

bemoeilijkt wordt. Dit vergroot de kans op IT security fouten binnen de webapplicaties.

Welke risico’s worden nu veelal afgedekt en welke maatregelen worden daarvoor genomen?

In hoofdstuk 4 zijn standaard methodieken behandeld welke kunnen worden gebruikt om inzicht te verkrijgen

in de beveiligingssituatie van webapplicaties. Deze best practices geven inzicht in zowel de technische

inrichting en architectuur van een applicaties als de ontwikkelprocessen van de webapplicaties. Hierbij kan

men inzicht krijgen in de risico’s zoals besproken in hoofdstuk 3. Er zijn hiervan 5 voorbeelden genoemd:

• Applicatie security;



• Infrastructuur security;

• Configuratie security;

• Source code security

• Secure Software Development;

Welke risico’s met betrekking op webapplicaties blijven in veel bedrijven onderbelicht tijdens een IT audit, wat

is de reden hiervan en wat kunnen de gevolgen hiervan zijn?

In hoofdstuk 5 is toegelicht dat de invalshoek tijdens IT audits niet gelijk is aan de invalshoek van een IT

security professional die een beveiligingstest uitvoert op een webapplicatie. De IT security professional zal zich

op de technische oplossingen richten, terwijl de auditor naast de techniek ook naar de organisatorische

aspecten van de applicatie kijkt. Doordat een auditaanpak uitgaat van traditionele applicaties en de processen

om deze applicaties, zullen juist de specifieke aspecten die uniek zijn voor webapplicaties onderbelicht blijven.

Indien de kwetsbaarheden benoemd in hoofdstuk 3 niet correct worden beoordeeld is het moeilijk een goed

oordeel te vormen over de werking van een webapplicatie. Door de kwetsbaarheden kan immers de data

gemanipuleerd worden of ongeautoriseerde toegang worden verkregen tot de (gevoelige) data.

Bestaan aanvullende manieren waarop auditors meer ‘zekerheid’ kunnen krijgen bij de beoordeling van

webapplicaties?

In hoofdstuk 5 is beschreven dat auditors niet alleen naar de technische risico’s maar ook naar de

organisatorische risico’s kijken. Hierdoor ligt de focus anders dan bij IT security professionals en zullen

meerdere onderdelen behandeld worden, maar zal het qua techniek minder de diepte in gaan. De (standaard)

frameworks die worden gebruikt als basis voor normenkaders besteden relatief weinig aandacht aan het

specifieke risicoprofiel van webapplicaties.

Wij zijn echter van mening dat tijdens audits op een effectieve wijze naar webapplicaties gekeken kan worden

door gebruik te maken van een (beperkte) set van de methodes die nu al worden gebruikt door IT security

professionals. Deze methodes zijn beschreven in hoofdstuk 4. Hierbij zullen de werkzaamheden, die door de

beheerder en ontwikkelaar(s) van de applicatie (of door externen) zijn uitgevoerd, moeten worden

beoordeeld. Daarbij kunnen minimale eisen gesteld worden aan de maatregelen die genomen zijn of de

werkzaamheden die zijn uitgevoerd. In hoofdstuk 6 hebben wij een aantal maatregelen beschreven die

specifiek voor webapplicaties uitgevoerd zouden kunnen worden. Op deze manier kunnen auditors meer

zekerheid verkrijgen in de maatregelen die bedrijven genomen hebben voor webapplicaties (het

ontwikkelproces, de uitgevoerde beveiligingstesten en de opzet van de infrastructuur van de applicaties).

Hiervoor kan bijvoorbeeld dezelfde aanpak worden gekozen als nu vaak voor besturingssystemen wordt

gekozen: Op het moment dat er een specifiek besturingssysteem wordt aangetroffen, zullen er een aantal

controle activiteiten worden gedefinieerd (meestal op basis van een standaard lijst) die specifiek voor deze

software van toepassing zijn. Als dit ook voor webapplicaties wordt gedaan, denken wij dat er een meer

adequate risicobeoordeling uitgevoerd kan worden bij het auditen van webapplicaties. Dit zal leiden tot een

effectievere audit van webapplicaties.

7.2 VERVOLG

Zoals in hoofdstuk 6.1 al genoemd dienen auditors een bepaalde kennis te bezitten voor de beoordeling van

de maatregelen die genomen zijn in webapplicatie. Als vervolgstappen voor het uitvoeren van IT audits op

webapplicaties zou een aanvullende training kunnen worden uitgewerkt die auditors de benodigde

inzicht/kennis kan geven omtrent webapplicaties. Deze training zal de specifieke risico’s op webapplicaties



kunnen benadrukken en bijvoorbeeld toespelen op de verschillen tussen bepaalde scriptingtalen of toelichten

wat de kenmerken zijn van bepaalde webservers en databases.

Naast deze trainingen zien wij de mogelijkheid dat een best practice document kan worden opgesteld met als

doel te dienen voor de basis van een normenkader voor webapplicaties. Deze zal dan gedetailleerde

controlemaatregelen kunnen bevatten die kunnen worden gecontroleerd in webapplicaties. Een voorbeeld

van een controlemaatregel, die hier in zou kunnen staan, is een invoercontrole door middel van een reguliere

expressie. Deze normenkaders dienen echter wel rekening te houden met de verschillen tussen de

programmeertalen en de onderliggende architectuur (webserver/middleware/database). Voor de

onderliggende infrastructuur en het veilig opzetten hiervan kan ook gebruik gemaakt worden van NIST SP 800-

95 [NIS07]. Dit document geeft hulpmiddelen voor het veilig opstellen van een Service Oriented Architecture

(SOA) ontwerp en ontwikkeling gebaseerd op Web Services.



APPENDIX I – BIBLIOGRAFIE

Referentie Beschrijving

[SEC09] – Security.nl, september 2009, Hacker kraakt websites ING, Dexia en HSBC,

http://www.security.nl/artikel/30826/1/Hacker_kraakt_websites_ING%2C_Dexia_en_HSBC.html

[RAM08] – Zulfikar Ramzan Ph.D. (Symantec), december 2008, Security Trends of 2008 and Predictions for

2009, http://www.net-security.org/article.php?id=1194&p=2

[PER09] – Sarah Perez, oktober 2009, Office Web Apps Expands, More Invited to Join Technical Preview,

http://www.readwriteweb.com/archives/office_web_apps_expands_more_invited_to_join_tech

_preview.php

[OWA10] – The Open Web Application Security Project, 2010, OWASP Top 10 – 2010, The ten most critical

web application security risks,

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf

[LEW98] – SCOTT M. LEWANDOWSKI, maart 1998, Frameworks for Component-Based Client/Server

Computing,

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.75.6712&rep=rep1&type=pdf

[AKN02] – Alan Knight , Naci Dai, maart/april 2002, Objects and the Web,

http://www.computer.org/portal/web/csdl/doi?doc=abs/html/mags/so/2002/02/s2051.htm

[TOP10] – OWASP Foundation, april 2010, Top 10 2010, http://www.owasp.org/index.php/Top_10_2010-

Introduction

[MEI05] – J.D. Meier, Alex Mackman, Blaine Wastell (Microsoft Corporation), mei 2005, Web Application

Security Frame, http://msdn.microsoft.com/en-us/library/ff649461.aspx

[NMA10] – Gordon Lyon, Insecure.Com LLC, http://www.nmap.org/

[TEN10] – Tenable Network Security(R), http://www.tenable.com/nessus/

[SUL08] – Chris Sullo, Cirt.net, 2008, http://www.cirt.net/nikto2

[CTC04] – Chinotec Technologies Company,2004, http://www.parosproxy.org/

[OPP04] – Priscilla Oppenheimer, mei 2004, Top-Down Network Design, Second Edition,

http://my.safaribooksonline.com/1587051524

[COO07] – Mark Cooksley, 2007, Best practice for network design,

http://www.ethernetschulungen.de/presentations/Network_Design.pdf

[BSI02] – Business Information (BSi), december 2002, Guide on the selection of BS 7799 Part 2 controls,

http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030106129

[ULL07] Dr. Johannes B. Ullrich, maart 2007, Web Application Auditing Over Lunch

http://www.sans.edu/resources/securitylab/audit_web_apps.php

[WIK10] – Wikipedia, juli 2010, Web 2.0



Referentie Beschrijving

http://nl.wikipedia.org/wiki/Web_2.0

[GOO10] – Google, 2010, Definitie Web application,

http://www.google.nl/search?hl=nl&q=define%3A+web+application&aq=f&aqi=&aql=&oq=&gs_

rfai=

Zie Appendix III

[OFF02] – Jeff Offutt (IEEE), april 2002, Quality Attributes of Web Software Applications,

http://www.computer.org/portal/web/csdl/abs/html/mags/so/2002/02/s2025.htm

[MAC08] – Richard MacManus, oktober 2008, Microsoft Office Comes to the Browser (Finally),

http://www.readwriteweb.com/archives/microsoft_office_comes_to_browser.php

[WAT07] – David Watson, oktober 2007, Web application attacks,

http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6VJG-4PXNF5W-7-

3&_cdi=6094&_user=499882&_orig=search&_coverDate=10%2F31%2F2007&_sk=979929989&vi

ew=c&wchp=dGLbVzb-zSkWz&md5=69ee58b68e9c6994a836f0d3e26635f9&ie=/sdarticle.pdf

[WAL08] – Chris Walters, januari 2008, Geeks.com Website Hacked, Customer Data Stolen,

http://consumerist.com/341408/geekscom-website-hacked-customer-data-stolen

[SEC09-2] – Security.nl, augustus 2009, Webwinkel Mozilla gehackt,

http://www.security.nl/artikel/30535/1/Webwinkel_Mozilla_gehackt.html

[BUY08] – R. Buyya, Chee Shin Yeo S. Venugopal, oktober 2008, Dept. of Comput. Sci. & Software Eng.,

Univ. of Melbourne, Melbourne, VIC

[OSA10] – Open Security Architecture, 2010, Definitie IT Risk

http://www.opensecurityarchitecture.org/cms/definitions/it-risk

Zie Appendix III

[MOZ09] – The Mozilla Blog, augustus 2009, Mozilla Store Vendor Security Breach,

http://blog.mozilla.com/blog/2009/08/04/mozilla-store-vendor-security-breach/

[NIS07] – Anoop Singhal, Theodore Winograd, Karen Scarfone, augustus 2007, Guide to Secure Web

Services, http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf



APPENDIX II – VERKLARENDE WOORDENLIJST

Afkorting Definitie

HTTP Hypertext Transfer Protocol (HTTP) is het protocol voor de communicatie tussen

een webclient (meestal een webbrowser) en een webserver. Dit protocol wordt

niet alleen veel op het World Wide Web gebruikt, maar ook op lokale netwerken

(we spreken dan van een intranet).

Bron: wikipedia

HTTPS Het protocol HTTPS staat voor HyperText Transfer Protocol Secure. HTTPS is een

uitbreiding op het HTTP-protocol met als doel een veilige uitwisseling van

gegevens. Bij gebruik van HTTPS worden de data versleuteld, waardoor het voor

een buitenstaander, bijvoorbeeld iemand die afluistert, onmogelijk zou moeten

zijn om te weten welke gegevens verstuurd worden.

Bron: wikipedia

Protocol Wanneer wij in dit document een protocol benoemen, bedoelen wij een

communicatieprotocol. Binnen de telecommunicatie is een communicatieprotocol

een set van regels en afspraken voor de representatie van data, signalering,

authenticatie en foutdetectie, nodig voor het verzenden van informatie over een

communicatiemedium. De communicatieprotocollen voor digitale computer

netwerken hebben vele eigenschappen bedoeld om ervoor te zorgen dat

betrouwbare data uitwisseling kan plaatsvinden over een onbetrouwbaar

communicatiekanaal of medium. Een communicatieprotocol is eigenlijk het

volgen van bepaalde regels, zodat een systeem goed kan communiceren en

daardoor informatie uit kan wisselen. Vaak zijn deze regels vastgelegd in een

standaard of norm.

Bron: wikipedia

Applicatie Een applicatie (letterlijk: toepassing) is een computerprogramma dat is bedoeld

om door de gebruiker direct te worden gebruikt. Dit in tegenstelling tot een

server-taak of andere taken die door een besturingssysteem in de achtergrond

worden uitgevoerd.

Bron: wikipedia

Dynamische webpagina’s Een dynamische webpagina is een webpagina die just-in-time wordt

samengesteld (gegenereerd), exact op het moment dat de bezoeker de pagina

opvraagt. Een website die uit dynamisch gegenereerde pagina's bestaat wordt

een dynamische website genoemd. Dit staat tegenover de statische website,

waarbij de HTML-pagina's reeds kant-en-klaar ingevuld op de webserver staan te

wachten om opgevraagd te worden door een gebruiker.



Afkorting Definitie

Bron: wikipedia

Web based (Als in web

based applicaties)

Webgebaseerd (in het Engels: web-based) is een term om een groep van

computersoftware aan te duiden die via het World Wide Web of een intranet

werkt. De gebruiker hoeft dus geen software op zijn/haar eigen computer te

installeren, maar kan via een webbrowser direct van het programma

gebruikmaken.

Bron: wikipedia

standalone applicaties Applicaties die geen verbinding via een netwerk nodig hebben om te kunnen

werken.

LDAP Lightweight Directory Access Protocol (LDAP) is een netwerkprotocol dat

beschrijft hoe gegevens uit directoryservices benaderd moeten worden over

bijvoorbeeld TCP/IP. Een directory is in dit verband informatie die op een

hiërarchische manier, gegroepeerd naar een bepaald attribuut, is opgeslagen.

Denk aan een telefoonboek waarin telefoonnummers en adressen van personen

per bedrijf worden opgeslagen. Een directorynaam komt overeen met de

bedrijfsnaam. Iedere directory bevat dan alle personen binnen dat bedrijf als

objecten, met contactgegevens zoals telefoonnummer en e-mailadres als

attributen.

Bron: wikipedia

XSS Cross-site scripting (XSS) is een benaming voor een type bedreiging voor de

beveiliging van computers die in webapplicaties kunnen voorkomen.

Het zelfde bron principe zegt dat een script van de ene bron niet de pagina en

gegevens, zoals cookies, van een andere bron mag lezen of wijzigen.

Wanneer een aanvaller het zelfde bron principe voor HTML-scripting probeert te

omzeilen spreekt men van cross-site scripting.

Bron: wikipedia

CSRF Cross-site request forgery is een benaming voor een type kwetsbaarheid van een

website, waarbij ongeautoriseerde acties worden verstuurd uit naam van een

vertrouwde gebruiker. Waarbij XSS het vertrouwen van de gebruiker in een

website misbruikt, misbruikt CSRF het vertrouwen van de browser van de

gebruiker in de website.

(Web)sessie Een belangrijk element van een webapplicatie is de gebruikersessie (in het Engels

session variables genoemd). Een gebruikersessie zorgt ervoor dat de verschillende

scripts van een applicatie weten welke gebruiker het script aanroept. Een

webbrowser ontvangt bij het opvragen van het eerste script van een applicatie

een speciaal cookie, het session cookie, dat een unieke waarde bevat. Een

browser stuurt dit cookie bij elke volgende aanvraag in de webapplicatie mee als

header. Op een webserver kan op basis van de unieke waarde van dit cookie,

worden bijgehouden of bijvoorbeeld de zender is aangemeld, en zo ja welke



Afkorting Definitie

gebruiker het is. Dit voorkomt dat gebruikers op elke pagina opnieuw moeten

aanmelden. Een webapplicatie kan op basis van de waarde van de session

variables een verschillende inhoud aan pagina's geven. Zo ziet elke aangemelde

gebruiker van een webmailapplicatie alleen eigen e-mailberichten en niet de

berichten van een andere gebruiker.

Bron: wikipedia

Phising sites Phishing is een vorm van internetfraude. Het bestaat uit het oplichten van

mensen door ze te lokken naar een valse (bank)website. Deze website is een

kopie van de echte website en ze daar bijvoorbeeld — nietsvermoedend — te

laten inloggen met hun inlognaam en wachtwoord of hun creditcard-nummer.

Bron: wikipedia

URL Een Uniform Resource Locator (afgekort URL) is een label dat verwijst naar een

informatiebron, bijvoorbeeld een webpagina of een ander bestand.

Bron: wikipedia

Perimeter beveiliging Een methode van beveiliging waarbij de maatregelen alleen aan de (buiten) rand

van een netwerk, besturingssysteem of applicatie worden genomen.

OWASP TOP-10 Webapplicaties kunnen kwetsbaarheden bevatten die door hackers kunnen

worden misbruikt. De kwetsbaarheden zijn door het Open Web Application

Security Project (OWASP) onderverdeeld in een tiental categorieën.

Bron: wikipedia

Secure SDLC Een Secure Systems/Software Development Life Cycle is een ontwikkelen

onderhoudsproces van een systeem of applicatie, waarbij de beveiliging van het

systeem of de applicatie in elke fase van het proces wordt behandeld en

ingebouwd.

Onderhoudbaarheid De onderhoudbaarheid van een applicatie is de resources die erin moet worden

gestopt in het onderhouden van een applicatie. Een voorbeeld hiervan is dat als

veel beveiligingsfouten in een webapplicatie zitten, veel meer resources zullen

moeten worden gestopt om de betrouwbare werking van de applicatie te kunnen

blijven waarborgen.

Schaalbaarheid Schaalbaarheid is de mogelijkheid van een applicatie, systeem, netwerk of proces

om meer data of gebruikers te verwerken. Dit wordt bewerkstelligd door (relatief

eenvoudig) de capaciteit te kunnen vergroten.

Reguliere expressie Een reguliere expressie is een methodiek waarvan de syntax formeel is

vastgelegd. Met een reguliere expressie kan men in een applicatie onder andere

een tekst doorzoeken op door de gebruiker opgegeven patronen.



APPENDIX III – ENKELE BRONVERMELDINGEN

Ter aanvulling van enkele bronvermeldingen hebben wij hier belangrijke paragrafen of onderdelen van

webpagina’s neergezet.

Referentie Kopie van brondocument

[GOO10] • In software engineering, a web application is an application that is accessed via a

web browser over a network such as the internet or an intranet:

en.wikipedia.org/wiki/Web_application

• An application that is delivered using internet technology and meets one or more of

the following conditions:

www.state.tn.us/guidelines/d.html

• There is a technical definition for web application (or web-app) somewhere within

the Java Servlet Specification, but for the purposes of this book, the term 'web

application' or 'web-app' will loosely point to any development project intended to

run on a web server and viewed by the customers:

www.wantii.com/wordpress/

• Web applications are stored on a server and delivered to users over the internet. A

Web application is usually a three-tier structure, comprising a User Service tier

(allowing user access to the application), a Business Service tier (allowing the user to

carry out complex activities) and a Data:

www.sitepoint.com/glossary.php

• Web 2.0 is a term used to describe the next stage of the internet where people do

more things on the internet rather than on their own computer and web-pages are

not just static pages of information. This includes doing things in a web-browser

such as reading your mail or word-processing:

www.puzzlepixies.com/help/help/computing-terms.html

• A website that contains pages with partly or entirely undetermined content. The

final content of these pages is determined only when a visitor requests a page from

the web server:

help.adobe.com/en_US/Dreamweaver/10.0_Using/WSEDF6B000-F0D9-

4565-9023-85171DCB4E47.html

• also known as a virtual server (in sharepoint v2) and an web site / application pool

(in iis), web apps allow for logical separation of sharepoint content. each web app

runs under a different process on the iis web server:

blogs.msdn.com/skelley/archive/2007/06/24/sharepoint-terminology-

defined.aspx

• Web programs or real programs designed to be used on the web site using a

browser. Example of web application would be e-commerce web site, web banking,

stock exchange on the web, web games and many others. Web applications are

becoming very popular due to wide availability of the internet access:

www.delicious-webdesign.com/website-design-uncovered.html



Referentie Kopie van brondocument

• A virtual server that resides on an HTTP server but appears to the user as a separate

HTTP server. Several Web applications can reside on one computer, each capable of

running its own programs and each having individualized access to input and

peripheral devices:

sharepointkb.wordpress.com/2008/08/20/sharepoint-terminology/

[OSA10] ISO:

IT Risk: The potential that a given threat will exploit vulnerabilities of an asset or group of

assets and thereby cause harm to the organization. It is measured in terms of a combination

of the probability of an event and its consequence [ISO/IEC 13335-1:2005]

NIST:

IT-Related Risk: The net mission impact considering (1) the probability that a particular

threat-source will exercise (accidentally trigger or intentionally exploit) a particular

information system vulnerability and (2) the resulting impact if this should occur. IT-related

risks arise from legal liability or mission loss due to—

1. Unauthorized (malicious or accidental) disclosure, modification, or destruction of

information

2. Unintentional errors and omissions

3. IT disruptions due to natural or man-made disasters

4. Failure to exercise due care and diligence in the implementation and operation of

the IT system. [NIST 800-53 rev2]

FAIR:

Risk: The probable frequency and probable magnitude of future loss.



APPENDIX IV – VRAGENLIJST INTERVIEWS

Deze appendix geeft de vragenlijsten weer die tijdens de interviews voor het praktijkonderzoek zijn gebruikt

als hulpmiddel om de verschillende onderwerpen te bespreken.

De vragen in de onderstaande tabel zijn de vragen voor de personen die deze beantwoorden vanuit een intern

oogpunt.

Onderwerp Vragen

Definitie Onder webapplicaties verstaan wij: “alle interactieve applicaties die door een gebruiker

middels een web-browser zijn te benaderen over het HTTP of HTTPS protocol.”

Is er binnen uw bedrijf een definitie en sluit dit aan? Zo niet, hoe beoordeelt u zelf

webapplicaties?

Trends Ziet u dat er meer webapplicaties worden ingevoerd in de laatste 5/10 jaar?

Is dit ook binnen uw bedrijf zo?

Zou u aan kunnen geven wat u als de belangrijkste oorzaken hiervan ziet? (wat zijn de

voordelen van webapplicaties?)

Applicaties Wat zijn de belangrijkste applicaties binnen uw bedrijf?

*Namen zijn niet verplicht, maar wel doelen te noemen

WebApplicaties Vallen deze applicaties onder onze definitie van webapplicaties?

Zo nee dan: Wat zijn de belangrijkste webapplicaties binnen uw bedrijf?

Voor wie zijn deze bedoeld?

Wie kunnen theoretisch deze applicaties benaderen?

Wat voor risico’s ziet u bij het gebruik van deze applicaties voor het bedrijf?

Aanpak

(beveiliging)

Welke aanpak (verschillende aanpakken) wordt gekozen voor de beveiliging?

Risico’s Wij denken dat door de voordelen van webapplicaties extra risico's worden

geïntroduceerd.

Onderkent u dit ook en welke risico’s dan?

*Aan te vullen met onze lijst (deze ook bespreken)

Aanpak (audit) Ziet u op dit moment verschillende aanpak tussen de audits van webapplicaties en

traditionele applicaties?

Gezien de bovengenoemde risico's bent u van mening dat dit wel zou moeten?

Audit Approach -

verbeteringen

Is binnen uw bedrijf de aanpak gewijzigd? Wordt er extra aandacht gegeven aan de

risico's tijdens beoordeling van webapplicaties?

Zijn er (belangrijke) risico's die volgens u onderbelicht blijven?

Hoe denkt u dat deze risico's het beste kunnen worden afgevangen/getest/beoordeeld?

Hoe efficiënt zijn deze maatregelen?



Vragen voor de personen die beantwoorden vanuit een extern oogpunt. Hierbij waren de geïnterviewde

personen werkzaam bij een bedrijf dat audit- of beveiligingswerkzaamheden uitvoert voor verschillende

partijen. Om deze reden hebben zij een bredere blik en willen we de antwoorden die we bij de interne

interviews verkregen hebben toetsen aan het marktbeeld van deze personen. Op deze:

Onderwerp Vragen

Definitie Onder webapplicaties verstaan wij: “alle interactieve applicaties die door een gebruiker

middels een web-browser zijn te benaderen over het HTTP of HTTPS protocol.”

Is er binnen uw bedrijf een definitie en sluit dit aan? Zo niet, hoe kijk beoordeelt u zelf

webapplicaties?

Trends Ziet u dat er meer webapplicaties worden ingevoerd in de laatste 5/10 jaar?

Kunt u dit vanuit uw kennis en ervaring bevestigen?

Zou u aan kunnen geven wat u als de belangrijkste oorzaken hiervan ziet (wat zijn de

voordelen van webapplicaties)?

Applicaties Ziet u ook verschuivingen in het type webapplicaties dat wordt ingezet?

Worden er ook bedrijfskritische applicaties gebruikt?

Bedrijf vs. Markt Wij zijn bij een bedrijf langs geweest met vragen over: Toegang, Risico, Aanpak

beveiliging. (de antwoorden doorspreken).

Is dit een beeld wat u in de markt ook ziet?

Waar zitten de verschillen?

Risico’s Wij denken dat door de voordelen van webapplicaties extra risico's worden

geïntroduceerd? Onderkent u dit ook en welke risico’s dan?

*Aan te vullen met onze lijst (deze ook bespreken)

Aanpak (audit) Ziet u op dit moment verschillende aanpak tussen de audits van webapplicaties en

traditionele applicaties?

Gezien de bovengenoemde risico's bent u van mening dat dit wel zou moeten?

Audit Approach -

verbeteringen

Is binnen de geïnterviewde bedrijven is de aanpak wel/niet gewijzigd? Hoe ziet u dit in

de markt?

Wordt er extra aandacht gegeven aan de risico's tijdens beoordeling van

webapplicaties?

Zijn er (belangrijke) risico's die volgens u onderbelicht blijven?

Hoe denkt u dat deze risico's het beste kunnen worden afgevangen/getest/beoordeeld?

Hoe efficiënt zijn deze maatregelen?

IT Audit in een Web 2.0 Wereld - VUrORE...Deze scriptie tracht antwoord te geven op deze vragen en...

Documents

Transcript of IT Audit in een Web 2.0 Wereld - VUrORE...Deze scriptie tracht antwoord te geven op deze vragen en...