Michiel van veen KPMG: De volgende stap in applicatiebeveiligingsonderzoeken
Upcoming SlideShare
Loading in...5
×
 

Michiel van veen KPMG: De volgende stap in applicatiebeveiligingsonderzoeken

on

  • 169 views

De laatste jaren neemt het aantal ITbeveiligingsincidenten sterk toe. Recente ...

De laatste jaren neemt het aantal ITbeveiligingsincidenten sterk toe. Recente
berichten over inbraken bij de FBI, CIA, Amerikaanse Senaat en bedrijven als
Sony en Nintendo laten de ernst zien van deze dreiging. Dergelijke incidenten
bevorderen het bewustzijn dat in vrijwel elk apparaat software zit. Van horloge tot
spaceshuttle, alles wordt bepaald door software. Hierdoor ontstaat de behoefte
om meer controle te krijgen en te houden op beveiliging in applicaties en het pad
naar de data die het ontsluit, om zo te bewaken dat de software precies doet
wat het moet doen en niet wat het niet moet doen.

Statistics

Views

Total Views
169
Views on SlideShare
169
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Michiel van veen KPMG: De volgende stap in applicatiebeveiligingsonderzoeken Michiel van veen KPMG: De volgende stap in applicatiebeveiligingsonderzoeken Document Transcript

  • 24 Informatiebeveiliging - nummer 5 - 2011 Source-code: de bron van applicatiebeveiliging De volgende stap in applicatiebeveiligingsonderzoeken Ing. M. (Michiel) van Veen RE MSc. CISA CISSP is als adviseur bij KPMG IT Advisory werkzaam in de groep Infor- mation Protection and Business Resilience. Michiel is specialist op het gebied van IT-beveiligingsadvies, IT audi- ting, IT-beveiligingsonderzoeken en penetratietesten. Zijn kennisgebied reikt van IT Governance tot technische beveiligingsimplementaties in detail: from board to bit. Hij is te bereiken via vanveen.michiel@kpmg.nl. De laatste jaren neemt het aantal IT- de software en eventuele ondersteu- Configuratiereviews hebben tot doel te beveiligingsincidenten sterk toe. Recente nende IT-infrastructuur zoals data- valideren of alle instellingen de juiste berichten over inbraken bij de FBI, CIA, bases, servers en netwerk. Dit wordt scheidingen technisch afdwingen.Voor Amerikaanse Senaat en bedrijven als zodanig uitgevoerd dat de eindge- veel gebruikte software (zoals Windows Sony en Nintendo laten de ernst zien bruikers op de juiste manier toegang besturingssystemen of Oracle databases) van deze dreiging. Dergelijke incidenten krijgen tot de software. worden zogeheten beveiligingsconfigu- bevorderen het bewustzijn dat in vrijwel • De eindgebruikers zetten de software ratiebaselines gebruikt. Deze baselines elk apparaat software zit. Van horloge tot in voor de ondersteuning van de uit zijn in feite controlelijsten met configu- spaceshuttle, alles wordt bepaald door te voeren taken en maken zo dus ratie-instellingen zoals die geïmplemen- software. Hierdoor ontstaat de behoefte gebruik van de software en de daarin teerd moeten zijn. Afwijkingen kunnen om meer controle te krijgen en te houden besloten data. soms leiden tot het doorbreken van de op beveiliging in applicaties en het pad scheidingen en daarmee tot ongeautori- naar de data die het ontsluit, om zo te Om de scheiding tussen deze groepen seerde toegang tot de software en data. bewaken dat de software precies doet te implementeren is het belangrijk het Penetratietesten hebben tot doel inzicht wat het moet doen en niet wat het niet pad van de gebruiker naar de data onder te verschaffen in de aanwezige beveili- moet doen. controle te hebben. Met behulp van gingszwakheden. Vaak wordt hiertoe met bijvoorbeeld authenticatie- en autorisa- speciale applicaties en IT-beveiligingspe- Om meer controle te krijgen over de tiemiddelen zoals een gebruikersnaam cialisten (ethical hackers) getracht zwak- applicatiebeveiliging is het noodzakelijk en wachtwoord, wordt de scheiding heden te identificeren door de software inzicht te krijgen in de aanwezige maat- technisch afgedwongen. Een applicatie- op zowel gebruikelijke als ongebruikelijke regelen en de benodigde maatregelen. beveiligingsonderzoek richt zich op de manieren te benaderen. De controles in Typisch worden applicatiebeveiligingson- technisch afgedwongen scheidingen. de software worden omzeild, waardoor derzoeken uitgevoerd om dit in kaart te Typisch worden configuratiereviews ongeautoriseerd toegang wordt verkre- brengen. In een applicatiebeveiligingson- en penetratietesten gebruikt voor het gen tot de software en data. derzoek staan de IT-controlemaatregelen onderzoek. centraal en daarmee dus de (functie) Configuratiereviews richten zich vooral scheiding tussen verschillende (gebrui- op de beheerders. Bevindingen uit dit kers)groepen. Een veel gehanteerde type onderzoek richten zich op het af- scheiding is die tussen eindgebruikers, dwingen van controle vanuit de software beheerders en ontwikkelaars. naar de eindgebruiker. Deze worden vervolgens naar beheerders gecom- • Ontwikkelaars staan aan de basis municeerd die de nodige aanpassingen van de behoeftevoorziening naar de doorvoeren in de IT-infrastructuur. Verder gebruikers. Zij vertalen de wensen en dragen zij zorg voor de periodieke contro- eisen in ondersteunende software. le van deze instellingen en waarborgen Daarmee dragen zij de verantwoorde- zo de effectiviteit van de maatregelen lijkheid om te zorgen dat de software over tijd. correct werkt. Penetratietesten richten zich vooral op de • Beheerders zorgen ervoor dat de Fig. 1. De nadruk van een applicatiebevei- eindgebruikers. Bevindingen uit dit type ligingsonderzoek ligt meer op IT-beheer in software in het IT-landschap wordt onderzoek richten zich op de mogelijk- plaats van softwareontwikkeling. opgenomen. Daartoe configureren zij heden die de eindgebruiker heeft in de
  • Informatiebeveiliging - nummer 5 - 2011 25interactie met de software. Ook deze beeld het aanpassen van financiële data,bevindingen komen uiteindelijk terecht het lezen van vertrouwelijke gegevens ofbij beheerders die de nodige maatre- het beschikbaar houden van systemen.gelen implementeren of aanscherpen. Vaak maakt een organisatie een vertaal-Daarnaast worden bevindingen die slag van rollen en verantwoordelijkhedenvoortkomen uit fouten in de software zelf en voert deze door in de applicatie.gecommuniceerd naar de ontwikkelaars. Het testen van de authenticatie enKortom, de bovenstaande onderzoeks- autorisatiemechanismen in een applica-methodes laten zien dat veel nadruk tie is een belangrijk onderdeel van eenligt op het beheren van IT en minder op applicatiebeveiligingstest. Bugs in de au-softwareontwikkeling. Dit is vreemd aan- thenticatie- en autorisatiemechanismengezien juist de softwareontwikkeling be- kunnen het gebruik van de applicatiepaalt in welke mate vereiste controlemaat­ ondermijnen omdat de scheidingen tus-regelen technisch worden afgedwongen sen gebruikers onderling wordt doorbro-in de source-code. Om in de behoefte van ken. Daarmee wordt feitelijk het modelmeer controle over applicatiebeveiliging van rollen en verantwoordelijkheden uit Fig. 2. Bugs in de source-code hebbente voorzien, dient ook de source-code zelf de organisatie doorbroken. Dat dit een een grote invloed op de applicatiebe-te worden onderzocht. Fig.1. geeft het veiliging. impact kan hebben op de beveiligingonderzoeksgebied duidelijk aan. blijkt uit de vele fraude-incidenten, priva- cyschendingen en recente beschikbaar-Source-code en haar rol in de De invloed van bugs op heidproblemen van websites. Een recentapplicatiebeveiligingsproblematiek applicatiebeveiliging voorbeeld is het stelen van meer danApplicaties worden geschreven door een Het valideren van de beoogde functiona- 130.000.000 credit­ ardnummers van de csoftwareontwikkelaar waarbij deze de liteit (eisen en wensen) ten aanzien van betalingsverwerker Hartland door eenwensen en eisen van de opdrachtgever de applicatie is nog relatief eenvoudig. aanval van buiten het bedrijf. [ITA,2010]in een ontwerp van source-code vertaalt. Ingewikkelder wordt het om vast te stel- Naast bugs die een functioneel karakterDie source-code wordt geschreven door len dat de applicatie ook niet doet wat hebben zoals authenticatie- en autorisa-ontwikkelaars die daarmee bepalen wat ze niet belooft. Biedt de applicatie meer tiemechanismen, zijn er ook non-functi-de applicatie wel en niet doet. Het is dus mogelijkheden aan voor eindgebruikers onele bugs. Een bekend voorbeeld is hetbelangrijk vast te stellen dat de applica- om data te benaderen dan de bedoeling gebrek aan invoervalidatie. Afhankelijktie aan de wensen en eisen voldoet. De is? Bijvoorbeeld zonder authenticatie en van het gebruik van deze invoer in de ap-applicatie moet doen wat zij belooft. Dit autorisatie? Of biedt de applicatie, zonder plicatie kan dit grote beveiligingsgevol-lijkt triviaal maar dat is het niet. Immers, dat het de bedoeling is, toegang tot on- gen hebben. Wanneer de ongevalideerdeeen applicatie wordt geschreven door derliggende IT-infrastructuur (databases, invoer bijvoorbeeld wordt gebruikt ommensen en die maken soms fouten. Deze servers en netwerk)? een achterliggende database te bevra-fouten (bugs) kunnen ervoor zorgen dat In applicaties speelt controle dus een gen, kan de gebruiker zelf extra database-de applicatie zich anders commando’s (SQL) toevoe-gedraagt dan verwacht. Om- Zeker bij grote applicaties is het vrijwel onmogelijk alle gendata opvragen, aanpas- alle en zo ongeautoriseerddat een applicatie al vrij snelcomplex wordt door de vele bugs in de software te ontdekken en te verhelpen sen of verwijderen. Hierdoorcommando’s in de source- kan een gebruiker allecode en hun onderlinge samenhang belangrijke rol. Een belangrijk aspect controles in de applicatie omzeilen. Neemen afhankelijkheden, is een bug snel geïn- van de controle is het vaststellen of een als voorbeeld een salarisadministratie. Detroduceerd. Bovendien zijn bugs door gevraagde actie wel is toegestaan. Alleen software zorgt ervoor dat personeel datde complexiteit moeilijk op te sporen. op die manier is het mogelijk preventief de salarisbetaling uitvoert niet dezelfdeEen softwareontwikkelaar moet immers te garanderen dat de computer op een medewerkers zijn als diegene die deberedeneren hoe een computer in een juiste manier reageert op een verzoek betaling controleren en autoriseren: func-bepaalde situatie omgaat met het opge- en zo dus doet wat hij belooft. Daarmee tiescheiding. Wanneer een gebruiker degeven commando. Ook het vervolgens is het authenticeren en autoriseren van invoervalidatiebug misbruikt kan hij zelfverhelpen van bugs is geen sinecure. gebruikers en hun acties een belangrijke de salarisbetaling direct via de databaseZeker bij grote applicaties is het vrijwel functionaliteit binnen een applicatie. Met doorvoeren en omzeilt daarmee alleonmogelijk alle bugs in de software te authenticatie en autorisatie kan een or- controles met alle gevolgen van dien.ontdekken en te verhelpen. ganisatie controle uitoefenen op bijvoor- Een top-10 lijst van veelvoorkomende
  • 26 Informatiebeveiliging - nummer 5 - 2011 bekeken. Zo wordt deze aanpak ook vaak Met behulp van tools wordt de volledige gebruikt om de software te koppelen aan source-code doorgelicht en worden de (beheer)kosten daarvan, omdat soft- statistische berekeningen gemaakt. De ware met lage kwaliteit veel en moeizaam uitkomst geeft vaak goede handvatten in onderhoud vergt. een onderzoek naar de beheerbaarheid, In de ISO-norm is applicatiebeveiliging als overdraagbaarheid en uitbreidbaarheid aspect gehangen onder ‘functionaliteit’. van de software. Deze classificering staat in contrast met Kwalitatieve onderzoeken worden die van functionele en non-functionele veelal met de hand uitgevoerd waar een eisen. Applicatiebeveiliging kan namelijk specialist de source-code in de diepte zowel functionele als non-functionele onderzoekt. Voor een applicatiebe- eisen hebben. Een functionele eis is veiligingsonderzoek betekent dit, dat Fig. 3. IT-beveiliging is van toepassing bijvoorbeeld als een gebruiker moet zich kwetsbaarheden worden gezocht die de op elk van de zes aspecten van de soft- kunnen authenticeren met behulp van beveiliging kunnen beïnvloeden. Zoals warekwaliteit ISO-norm. een gebruikersnaam en wachtwoord. eerder besproken kan applicatiebevei- Een non-functionele eis is als het wacht- liging functioneel en non-functioneel applicatiefouten is terug te vinden in de woord opgeslagen dient te worden met worden geïmplementeerd. In een source- OWASP top 10 [OWASP,2010]. behulp van een one-way-hash-functie. code review is het belangrijk om beide Kortom, de source-code heeft grote in- Dit betekent dat applicatiebeveiliging benaderingen mee te nemen. vloed op applicatiebeveiliging. Fig. 2. laat niet te plaatsen is onder ‘functionaliteit’ in duidelijk zien welke invloed de bugs in de ISO-norm. Wanneer applicatiebeveili- • De eerste stap in het onderzoek is source-code hebben op de applicatiebe- ging met de softwarekwaliteittaxonomie een lexicale analyse. In deze stap veiliging. Dit wordt vergele- wordt onderzocht of de source-code betekent dat Het is belangrijk om in een applicatie­ ken, blijkt dat gestructureerd is, alles goed is ge- het belangrijk applicatiebe- documenteerd in de code, program- is om in een beveiligingsonderzoek ook onder de veiliging op meerstandaarden worden toegepast, applicatiebe- motorkap te kijken: source-codeonderzoek elk van de zes variabelendeclaraties consistent veiligingson- kenmerken zijn en de code goed leesbaar is. derzoek ook onder de motorkap te kijken invloed heeft en dus als integraal onder- De lexicale analyse geeft een eerste van de software om de interne werking deel van softwarekwaliteit beschouwd indruk van de source-codekwaliteit en vast te stellen, een source-codeonder- dient te worden. Daarmee heeft de mogelijke probleemgebieden. zoek. implementatie van de applicatiebeveili- • De tweede stap in het onderzoek is ging in software een grote invloed op de de control flow relation analyse. In Het uitvoeren van een source- kwaliteit van de software en dus op het codeonderzoek functioneren van de software in brede De aanpak voor het onderzoeken van zin. In fig.3. is de positie van IT-beveiliging source-code is sterk afhankelijk van de weergegeven in relatie tot de ISO-norm- vereiste breedte en diepgang.Twee be- aspecten. kende aanpakken zijn het onderzoeken Source-code reviews richten zich op van de kwaliteit van software en source- de diepgang en minder op de breedte. code reviews. Het reviewen van source-code specifiek Een bekende invulling van de kwaliteit voor applicatiebeveiliging is minder van software is gegeven in de ISO-norm bekend dan softwarekwaliteitsonder- 9126. De norm verdeelt de kwaliteit van zoeken. Praktische methodes die zich software op basis van de volgende ken- op applicatiebeveiliging focussen zijn merken: functionaliteit, betrouwbaarheid, [McGraw,2001] [McGraw,2004] [Mc- bruikbaarheid, efficiëntie, onderhoud- Graw,2006]. Bij het reviewen van source- baarheid en overdraagbaarheid. Door het code wordt onderscheid gemaakt tussen onderzoeken van deze aspecten ontstaat kwantitatief en kwalitatief onderzoek. In het beeld of men kan vertrouwen op de een kwantitatief onderzoek worden vaak software. Daarmee beslaat dit onderzoek aspecten bekeken zoals complexiteitsme- Fig. 4. De relatie tussen lexicale analyse en control flow relation-analyse van de meer dan de source-code alleen. De kwa- trieken, codeduplicatie, functiegroottes, source-code. liteit van de software wordt in zijn geheel overervingen in objectenstructuren enz.
  • Informatiebeveiliging - nummer 5 - 2011 27 deze stap loopt de onderzoeker door een beveiligingslek, dan wordt de in een realistische situatie zou kunnen de source-code heen op basis van de desbetreffende source-code op- doen. Samen met een configuratiereview functieaanroepen in de applicatie. gezocht. In de source-codeanalyse kan de applicatiebeveiligingstest com- Zo worden de stappen gevolgd die wordt vervolgens gevalideerd of er pleet worden gemaakt. de applicatie zelf doorloopt bij het sprake is van een beveiligingslek. uitvoeren van acties. De nadruk ligt Conclusie op aspecten als foutafhandeling, De keuze van de aanpak hangt samen Traditionele benaderwijzen van penetra- (technische) aannames, design pat- met het doel van de applicatiebeveili- tietesten en configuratiereviews voor het terns, code hergebruik en logische gingstest. Wanneer het doel van de test is testen van applicatiebeveiliging komen objectstructuren. om zoveel mogelijk beveiligingslekken op onder druk te staan door het toenemend te sporen en hiervoor aanbevelingen aan aantal inbraakpogingen op applicaties.De control flow relation analyse richt te dragen, dan is een bottom-up-aanpak Dit stimuleert de vraag naar een aanvul-zich op de keten als geheel. De lexicale het meest geschikt. Door het integraal ling in de huidige aanpak: source-code-analyse op iedere schakel in die keten. analyseren van review. Door eenIn fig. 4. is deze relatie goed te zien. De de source-code Top-down en bottom-up:  source-codereviewresultaten uit beide stappen leveren een worden alle moge- kan applicatiebevei-goed overzicht op van beveiligingskwets- lijkheden geïden- wat kan een anonieme hacker in liging, als belang-baarheden veroorzaakt door de manier tificeerd en reële een realistische situatie doen? rijke invloed van devan source-code schrijven of door de dreigingen zicht- softwarekwaliteit,functionele samenhang van applicatieon- baar gemaakt met een penetratietest. verder worden beheerst. Dit voorkomtderdelen. Wanneer het doel is om vast te stellen dat eindgebruikers de software anders wat een anonieme aanvaller zou kunnen laten gedragen (manipulatie) of deSource-codeonderzoek als onderdeel van (ontdekken) is een top-down-aanpak software meer laten doen dan de bedoe-een applicatiebeveiligingsonderzoek logischer. Immers, de anonieme aanvaller ling is (injectie). Net als de voor de handZoals besproken bestaat het uitvoeren heeft geen beschikking over de source- liggende functionele en non-functionelevan een applicatiebeveiligingstest typisch code (afhankelijk van het open source- ­ isen, dienen ook applicatiebeveiligings- euit een penetratietest, eventueel gecom- karakter) en zal die dus niet als basis eisen expliciet te worden opgesteld aanbineerd met een configuratiereview. Een gebruiken. Wel kan de source-codeana- het begin van de software-ontwikkel-source-codereview is geen vervanging lyse worden gebruikt om de efficiëntie cyclus. Dit waarborgt dat de applicatie-van deze aanpak maar juist een belang- van de penetratietest te verhogen. Bij een beveiliging al tijdens de software-ont-rijke aanvulling daarop. Deze aanvulling penetratietest is de tijd vaak gelimiteerd, wikkeling wordt getest. Met voldoendehelpt bij het identificeren van meer en terwijl een echte aanvaller meer tijd en aandacht voor applicatiebeveiliging en incomplexe kwetsbaarheden in applicaties resources tot zijn beschikking heeft. juiste balans met gebruikersvriendelijk-binnen een kortere tijd. Dit is duidelijk te Het is verstandig om de top-down- en heid wordt zo veiligere software ontwik-zien in fig.5. bottom-up-aanpak te combineren. keld en gebruikt. Daarmee kan de samen-Het uitvoeren van een source-codereview Hierdoor worden zoveel mogelijk beveili- leving verder steunen en vertrouwen opin het kader van een applicatiebeveili- gingskwestbaarheden ontdekt en wordt een juiste ondersteuning door software.gingstest kan op twee manieren worden tevens bepaald wat een anonieme hackeringezet. Literatuur Identity Theft Awareness. 2010 Security Incidents,• Bottom-up-aanpak www.identity-theft-awareness.com/ In een bottom-up-aanpak wordt eerst 2010-security-incidents.html, 2010 begonnen met het analyseren van de ISO/IEC 9126-1:2001. Software engineering - Product quality - Part 1: Quality model. www.iso.org/iso/ source-code. Daarmee worden moge- iso_catalogue/catalogue_tc/catalogue_detail. lijke zwakheden geïdentificeerd. Deze htm?csnumber=22749, 2011 zwakheden worden vervolgens in een McGraw et al. Secure Software: How to Avoid Secu- penetratietest gevalideerd. Hierdoor rity Problems the Right Way, 2001 worden ‘false-positives’ eruit gehaald. McGraw et al. Exploiting Software: How to Break Code, 2004• Top-down-aanpak McGraw et al. Software Security: Building Security In een top-down-aanpak wordt eerst Fig. 5. Het verband tussen een penetra­tie­ In, 2006 test, configuratiereview en een source- begonnen met een penetratietest. OWASP. OWASP top 10,www.owasp.org, 2010 code review. Wanneer vermoedens bestaan van