IT Audit in een Web 2.0 Wereld

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

IT Audit in een Web 2.0 Wereld

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

IT Audit in een Web 2.0 Wereld 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


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

3


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.


4


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


5

IT Audit in een Web 2.0 Wereld 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.


6

IT Audit in een Web 2.0 Wereld De resultaten van dit onderzoek zijn in combinatie met het literatuuronderzoek de input voor de beantwoording van de 4e en 5e 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.


7


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

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.


8

IT Audit in een Web 2.0 Wereld 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 1 services middels webapplicaties aanbiedt . 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: http://www.google.nl/intl/nl/options/


9

IT Audit in een Web 2.0 Wereld 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.


10


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.


11

IT Audit in een Web 2.0 Wereld 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.


12


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.


13

IT Audit in een Web 2.0 Wereld 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 top10. 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 FIGUUR 2 - BEVEILIGING OP ALLE PLAATSEN IN HET dit niet in lijn te zijn met het verhoogde risicoprofiel van ONTWIKKELPROCES 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.


14

IT Audit in een Web 2.0 Wereld 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.


15


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

IT Audit in een Web 2.0 Wereld 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

IT Audit in een Web 2.0 Wereld 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

IT Audit in een Web 2.0 Wereld 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 Top10 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.


19

IT Audit in een Web 2.0 Wereld 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.


20


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.


21

IT Audit in een Web 2.0 Wereld 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.


22


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.


23

IT Audit in een Web 2.0 Wereld 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.


24

IT Audit in een Web 2.0 Wereld 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 bruteforce 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)


25

IT Audit in een Web 2.0 Wereld 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 4

Zie ook http://cirt.net/ Bron: http://news.netcraft.com/archives/2010/01/


26

IT Audit in een Web 2.0 Wereld 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.


27


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;


28

IT Audit in een Web 2.0 Wereld • • • •

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


29

IT Audit in een Web 2.0 Wereld 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 80095 [NIS07]. Dit document geeft hulpmiddelen voor het veilig opstellen van een Service Oriented Architecture (SOA) ontwerp en ontwikkeling gebaseerd op Web Services.


30


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_2010Introduction

[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]

[WIK10]

Dr. Johannes B. Ullrich, maart 2007, Web Application Auditing Over Lunch http://www.sans.edu/resources/securitylab/audit_web_apps.php – Wikipedia, juli 2010, Web 2.0


31

IT Audit in een Web 2.0 Wereld 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-73&_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] [OSA10]

[MOZ09] [NIS07]

– R. Buyya, Chee Shin Yeo S. Venugopal, oktober 2008, Dept. of Comput. Sci. & Software Eng., Univ. of Melbourne, Melbourne, VIC – Open Security Architecture, 2010, Definitie IT Risk http://www.opensecurityarchitecture.org/cms/definitions/it-risk Zie Appendix III – The Mozilla Blog, augustus 2009, Mozilla Store Vendor Security Breach, http://blog.mozilla.com/blog/2009/08/04/mozilla-store-vendor-security-breach/ – Anoop Singhal, Theodore Winograd, Karen Scarfone, augustus 2007, Guide to Secure Web Services, http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf


32


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.


33

IT Audit in een Web 2.0 Wereld 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


34

IT Audit in een Web 2.0 Wereld 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.


35


APPENDIX III – ENKELE BRONVERMELDINGEN Ter aanvulling van enkele bronvermeldingen hebben wij hier belangrijke paragrafen of onderdelen van webpagina’s neergezet. Referentie [GOO10]

Kopie van brondocument •

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


36

IT Audit in een Web 2.0 Wereld 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.


37


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?


38

IT Audit in een Web 2.0 Wereld 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.”

Trends

Is er binnen uw bedrijf een definitie en sluit dit aan? Zo niet, hoe kijk beoordeelt u zelf webapplicaties? 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?

Bedrijf vs. Markt

Worden er ook bedrijfskritische applicaties gebruikt? Wij zijn bij een bedrijf langs geweest met vragen over: Toegang, Risico, Aanpak beveiliging. (de antwoorden doorspreken).

Risico’s

Aanpak (audit)

Audit Approach verbeteringen

Is dit een beeld wat u in de markt ook ziet? Waar zitten de verschillen? 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) 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? 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?


39

IT Audit in een Web 2.0 Wereld

Recommend Documents