IT Audit in een Web 2.0 Wereld

Transcriptie

1 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. ing. C. (Coen) Steenbeek, MSc. CISSP 9 oktober 2010 Versie 1.0.2

2

3 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 Coen Steenbeek & Steven Raspe 1

4 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. Coen Steenbeek & Steven Raspe 2

5 INHOUDSOPGAVE SAMENVATTING... 1 INHOUDSOPGAVE... 3 VOORWOORD INLEIDING VRAAGSTELLING ONDERZOEKSMETHODOLOGIE AFBAKENING WEBAPPLICATIES & TRENDS WEB 2.0 EN WEBAPPLICATIES Definitie: Webapplicaties Definitie: Web WEBAPPLICATIE TRENDS RISICO S IN EEN WEBAPPLICATIE OMGEVING RISICO S OF VERANDERINGEN IN HET RISICOPROFIEL RISICO S EN RISICOVERANDERINGEN OP BASIS VAN DE LITERATUURSTUDIE Standaardkwetsbaarheden Bereikbaarheid RISICO S EN RISICOVERANDERINGEN OP BASIS VAN HET PRAKTIJKONDERZOEK Ontwikkelproces Onderhoud CONCLUSIES BEST PRACTICES VOOR BEVEILIGING IN EEN WEBOMGEVING INFRASTRUCTUUR SECURITY APPLICATIE SECURITY CONFIGURATIE SECURITY SECURE SOFTWARE DEVELOPMENT SOURCE CODE SECURITY DE IT-AUDITOR EN WEBAPPLICATIES AUDIT AANPAK BESTAANDE OPLOSSINGEN PRAKTIJK ADVIES BEOORDELING BEVEILIGINGSTESTEN MATE VAN ZEKERHEID CONCLUSIE CONCLUSIE VERVOLG APPENDIX I BIBLIOGRAFIE APPENDIX II VERKLARENDE WOORDENLIJST APPENDIX III ENKELE BRONVERMELDINGEN APPENDIX IV VRAGENLIJST INTERVIEWS Coen Steenbeek & Steven Raspe 3

6 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; Controls Analyst, Senior Compliance Analyst en 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; IT Security Architect en IT Auditor, internal audit vanuit een externe organisatie en Martijn Knuiman (IT Auditor Deloitte) voor de interviews ter toetsing van onze conclusies en bevindingen. Coen Steenbeek & Steven Raspe 4

7 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 webschil), 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). Coen Steenbeek & Steven Raspe 5

8 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. Coen Steenbeek & Steven Raspe 6

9 De resultaten van dit onderzoek zijn in combinatie met het literatuuronderzoek de input voor de beantwoording van de 4 e 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. Coen Steenbeek & Steven Raspe 7

10 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: DEFINITIE: WEBAPPLICATIES Onder webapplicaties verstaan wij: alle interactieve applicaties die door een gebruiker middels een webbrowser 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 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. Coen Steenbeek & Steven Raspe 8

11 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 aanbiedt 1. Ook zijn er steeds meer traditionele applicaties, soms zelfs standalone 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: Coen Steenbeek & Steven Raspe 9

12 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 adres, 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. Coen Steenbeek & Steven Raspe 10

13 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. Risico Risico Risico Risico Risico FIGUUR 1 - DE RISICO'S VAN WEBAPPLICATIES DOEN ZICH VOOR OP MEERDERE POSITIES 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. Coen Steenbeek & Steven Raspe 11

14 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) A5: Cross-Site Request Forgery (CSRF) 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. 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. Coen Steenbeek & Steven Raspe 12

15 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 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 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. Coen Steenbeek & Steven Raspe 13

16 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 en 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 FIGUUR 2 - BEVEILIGING OP ALLE PLAATSEN IN HET ONTWIKKELPROCES 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 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. Coen Steenbeek & Steven Raspe 14

17 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. Coen Steenbeek & Steven Raspe 15

18 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 Coen Steenbeek & Steven Raspe 16

19 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 Coen Steenbeek & Steven Raspe 17

20 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 Coen Steenbeek & Steven Raspe 18