Informatiebeveiliging voor testmanagement

Informatiebeveiliging voor testmanagement SYSQA B.V. Almere Datum : 31-03-2013 Status : definitief Opgesteld door:

Organisatie SYSQA B.V. Pagina 1 van 25 Inhoudsopgave 1 Inleiding.... 2 1.1 Relatie met andere documenten van expertisegroep Security... 2 1.2 Doel en veronderstelde voorkennis.... 2 2 Het Security Testing Proces... 3 2.1 Security testing in the Sofware Development Life Cycle... 3 2.2 Security testing versus andere testvormen... 4 2.3 Soorten aanvallen.... 4 2.4 Uitvoering.... 5 3 Informatiebeveiliging in het testproces... 7 3.1 Huidige situatie ( Ist )... 7 3.2 Gewenste situatie ( Soll )... 7 3.2.1 Unit test... 9 3.2.2 Testen van bibliotheken en uitvoerbare bestanden...10 3.2.3 Integratietest...11 3.2.4 Systeemtest...11 3.2.5 Penetratietesten....12 3.2.6 Stress test...12 3.3 Toepassen van reviewtechnieken...13 3.4 Testen met Abuse cases...15 3.5 Tooling...16 3.6 De operationele fase...16 4 Tenslotte... 18 5 Bijlage 1. OWASP Testing Checklist... 19 6 Bijlage 2. White box approach to Security Testing... 22 7 Bijlage 3. Literatuurlijst... 24

Organisatie SYSQA B.V. Pagina 2 van 25 1 Inleiding. Diverse SYSQA-medewerkers zijn in de rol van tester, testcoördinator, testmanager of een andere rol actief (geweest) in een testtraject. Daarbij zijn verschillende testvormen toegepast bij het functioneel testen van applicaties van uiteenlopende aard, met als doel vast te stellen in welke mate de applicatie voldoet aan de functionele specificaties en in welke mate aandacht is besteed aan de diverse kwaliteitscriteria en requirements. Het testen van de beveiliging van deze applicaties is een aspect waar, ondanks de toename van het aantal pogingen van hackers om zich toegang te verschaffen tot de digitale eigendommen van ondernemingen, in onze dagelijkse praktijk weinig aandacht aan wordt besteed. De verschillende testmethodieken dwingen ook niet tot het rekening houden met en plannen van testactiviteiten t.b.v. de beveiliging van de applicaties. Meestal wordt volstaan met het testen van de toegangsbeveiliging met gebruikersnaam en wachtwoord en de daaraan gekoppelde bevoegdheden. 1.1 Relatie met andere documenten van expertisegroep Security De expertisegroep Security van SYSQA B.V. heeft een set van documenten over informatiebeveiliging opgeleverd. Onderstaand plaatje is een weergave van alle documenten die de expertisegroep heeft geproduceerd en de plaats van dit document binnen het geheel. Introductie Informatiebeveiliging Basiskennis Informatiebeveiliging Informatiebeveiliging voor Requirementsanalist Informatiebeveiliging voor Testmanagement Informatiebeveiliging voor Functioneel Beheer Informatiebeveiliging voor Kwaliteitsmanager In donkerblauw is het voorliggende document weergegeven. 1.2 Doel en veronderstelde voorkennis. Dit document heeft niet de intentie de theorie van het testen te beschrijven. Daar is al genoeg over geschreven door verschillende deskundigen. Er wordt dan ook vanuit gegaan dat de lezer van dit document kennis heeft van en ervaring heeft met het testen. Doel van dit document is het onder de aandacht van alle SYSQA-medewerkers (en andere belangstellenden) brengen van de noodzaak van opname van het testen van beveiliging in het normale test(management)proces en het vergroten van het bewustzijn bij opdrachtgevers t.a.v. dit onderwerp. Tevens worden handvatten geboden voor testmanagers/ testcoördinatoren bij de invulling van hun rol bij de klant en worden aspecten van het testen van beveiliging in de verschillende testfasen belicht die voor testers interessant zijn. Ze laten namelijk zien wat de verschillen zijn tussen het testen van de beveiliging van systemen en het testen van systemen zonder aandacht voor de beveiliging van deze systemen. Voor begripsbepaling m.b.t. het onderwerp informatiebeveiliging wordt verwezen naar het document Basiskennis Informatiebeveiliging, dat ook te vinden is in de Kennisbank van SYSQA.

Organisatie SYSQA B.V. Pagina 3 van 25 2 Het Security Testing Proces 2.1 Security testing in the Sofware Development Life Cycle Het testen van beveiliging (security testing) kan een tijdrovend proces zijn, dat begint in de eerste fase van de Software Development Life Cycle (SDLC). Van dit proces worden in de literatuur [1] twee noodzakelijke benaderingen genoemd, namelijk: Testen van beveiligingsmechanismen om er zeker van te zijn dat hun functionaliteit op de juiste wijze is geïmplementeerd; Het uitvoeren van risico gebaseerd testen van beveiliging (risk-based security testing) gebaseerd op het begrijpen en simuleren van de werkwijze van de aanvaller. Onderstaande figuur laat zien waar gedurende de ontwikkeling van het te testen systeem de activiteiten m.b.t. het testen van de beveiliging kunnen worden uitgevoerd. Figuur 1. Security Testing flow throughout the software development Life cycle Degenen die verantwoordelijk zijn voor software security, voeren verschillende taken uit t.b.v. het beheren / beheersen van software security risico s, zoals: Creëren van security abuse/misuse cases; Beschrijven van normatieve security requirements; Uitvoeren van risico analyses op architectuur niveau; Ontwerpen van risico-gebaseerde security testplannen; Hanteren van statische analyse tools; Uitvoeren security tests; Uitvoeren penetratietest in de omgeving voorafgaand aan de productieomgeving; Opruimen na ontstaan/ontdekking van beveiligingslekken. In dit kader dient te worden gedacht aan security officers, ontwerpers, architecten, requirementsanalisten, functioneel beheerders, technisch beheerders en testspecialisten. In onderstaande tabel is te zien welke reviews, analyses en tests kunnen worden uitgevoerd in de verschillende fasen van de levenscyclus van software: Life Cycle Phase Requirements Architecture/Product Design Detailed Design Coding/Unit Testing Assembly/Integration Testing Reviews/tests Security review of requirements and abuse/misuse cases Architectural risk analysis (including external reviews) Security review of design. Development of test plans, including security tests. Code review (static and dynamic analysis), white box testing Black box testing (fault injection, fuzz testing)

Organisatie SYSQA B.V. Pagina 4 van 25 Life Cycle Phase System Testing Distribution/Deployment Maintenance/support Reviews/tests Black box testing, vulnerability scanning Penetration testing (by software testing expert), vulnerability scanning, impact analysis of patches (Feedback loop into previous phases), impact analysis of patches and updates 2.2 Security testing versus andere testvormen Testen van beveiliging verschilt van het functioneel testen of welke vorm van testen dan ook. Testen van beveiliging (security testing) is gedefinieerd als een proces ter identificatie van de verschillende kwetsbaarheden in een systeem als gevolg van een ontwerp dat niet aan de beveiligingseisen voldoet of als gevolg van onregelmatigheden in de codering. Dreigingen op applicatieniveau kunnen niet worden voorkomen door firewalls in het netwerk wanneer data is opgenomen in http berichten die door deze firewalls worden doorgelaten. Dus wordt het nog belangrijker om op applicatieniveau in plaats van op netwerkniveau aandacht te besteden aan de beveiliging. Het verschil tussen software veiligheid en software beveiliging is de aanwezigheid van een hacker die er op uit is onrechtmatig toegang te krijgen tot het systeem. Veiligheid dient altijd te worden bekeken in relatie tot de informatie en diensten die dienen te worden beschermd, de vaardigheden en middelen die de tegenstander ter beschikking heeft en de kosten van potentiële beschermende maatregelen. Het is een oefening in het beheersen van risico s. Risicoanalyse, in het bijzonder op het ontwerpniveau, kan helpen potentiële beveiligingsproblemen en hun impact te identificeren. 2.3 Soorten aanvallen. De meest voorkomende aanvallen op applicatie-niveau zijn [2]: Manipulatie verborgen velden. Cookie poisoning. Buffer overflow. Stealth Omdat de broncode van een webpagina vaak gemakkelijk toegankelijk is, geeft dit de mogelijkheid tot het bekijken van verborgen velden. Deze velden worden meestal gebruikt om statusinformatie door te geven aan de server. Helaas geeft dit echter ook de mogelijkheid tot misbruik van deze velden. Als je naar een (fysieke) winkel gaat waar men camera s verkoopt, kom je meestal niet zo gemakkelijk achter de balie of kun je de prijs van deze camera niet zo gemakkelijk wijzigen zonder dat de eigenaar van de winkel dit merkt. Thuis via internet gaat dit meestal wel onopgemerkt door de verborgen velden te manipuleren. Omdat cookies worden verzonden van de server naar de browser en gemakkelijk te bekijken en te wijzigen zijn, geeft dit een mogelijkheid om de server aan te vallen. Als de applicatie geen rekening houdt met veranderingen in de cookies, kan dit misbruikt worden voor het wijzigen van datavelden, het bekijken van ongeautoriseerde informatie of het geven van mogelijkheden om zich voor te doen als een andere gebruiker. Door de server meer informatie te geven dan die verwacht (bijvoorbeeld een tekst met tienduizend tekens in plaats van het maximum aantal van 25 tekens) kan dit leiden tot het vastlopen van de server, uitvoeren van gewijzigde code en het overschrijven van kritische systeemdata. Het veranderen van inputvelden in webformulieren kan ertoe leiden dat

Organisatie SYSQA B.V. Pagina 5 van 25 commanding. Parameter tampering. Misconfiguratie. Cross-site scripting/ forceful browsing. Database manipulatie. de webserver ongeoorloofde acties uitvoert. Versturen van gemodificeerde data naar webservers kan ertoe leiden dat deze alle member records in de database terugmeldt. Servers en standaardapplicaties zijn zelden standaard ingesteld met beveiliging. Indien dit achterwege wordt gelaten bij installatie kan dit leiden tot misbruik. Het gebruik van de adreslijn om acties uit te voeren. Dit wordt vaak gedaan door een script-tag toe te voegen aan de URL. Zoals met cookie poisoning, kan dit commando worden uitgevoerd of kan worden uitgebroken uit de servers rootdirectory als de applicatie dit niet voldoende afvangt. Vrij in te vullen velden/formulieren kunnen worden gebruikt voor het injecteren van SQL-commando s. Hiermee kan de database worden gelezen of worden gewijzigd. 2.4 Uitvoering. Volgens de auteurs van IT-beveiligingstesten als onderdeel in IT-audits [3] is het uitvoeringsproces van een IT-beveiligingstest terug te brengen tot de volgende stappen: mapping, scanning en exploiting. De keuze van deze stappen, samen met de objecten, bepaalt de mate van binnendringen. Ze herkennen hierbij de volgende onderverdeling: vulnerability assessment, penetration testing en red teaming. Het verschil hiertussen is het beste uit te leggen aan de hand van onderstaande figuur. Figuur 2. Overzicht van soorten IT-beveiligingstesten In de mappingfase wordt gekeken welke systemen aanwezig zijn in het netwerk en welke services actief zijn op die systemen. Tevens worden metadata uit zoekmachines of andere publieke bronnen geraadpleegd. In de scanningfase worden versies van software herkend en worden de objecten onderworpen aan scans op zoek naar zwakheden. Deze twee fasen samen zijn onderdeel

Organisatie SYSQA B.V. Pagina 6 van 25 van een 'vulnerability scan' of vulnerability assessment (het proces van identificeren, kwantificeren en prioriteren (of rangschikken) van zwakheden in een systeem). In deze twee stappen wordt veel gebruik gemaakt van geautomatiseerde tools. Een volledige penetratietest omvat ook de derde stap: exploiting. In deze stap worden gevonden zwakheden uitgebuit om zo in de systemen te kunnen inbreken. Dat kan door middel van een exploit, stukken programmacode die een kwetsbaarheid uitbuiten. De aanvaller laat het object in kwestie acties uitvoeren die de aanvaller toegang verschaffen. Na een succesvolle exploitingfase heeft de aanvaller toegang verkregen tot het object met bijbehorende gegevens. De term red teaming is een uitbreiding op penetratietesten en is afkomstig uit de militaire wereld waar het in gevechtsimulaties wordt gebruikt. Bij red teaming is het doel het belangrijkste. De trukendoos mag volledig open; alle acties die men kent mogen worden gebruikt. Bij IT-beveiligingstesten kan men hierbij denken aan een bedrijf dat louter is geïnteresseerd of inbreken mogelijk is, in de brede zin van het woord. Een combinatie van social engineering (manipuleren van mensen), phishing (ontlokken van gevoelige informatie, zoals gebruikersnaam en wachtwoord) en war driving (zoeken naar en toegang verkrijgen tot het draadloos netwerk van het bedrijf) met interne en externe penetratietesten kan dan bijvoorbeeld worden gebruikt om het doel te bereiken. War dialing is een hackingtechniek waarbij een computer een bereik van telefoonnummers van bijvoorbeeld een bedrijf systematisch afbelt om zo een modem of ander toegangspunt te ontdekken waarlangs de hacker het netwerk kan binnendringen. War driving is een vergelijkbare, maar modernere aanvalsvorm.

Organisatie SYSQA B.V. Pagina 7 van 25 3 Informatiebeveiliging in het testproces 3.1 Huidige situatie ( Ist ). Waar en op welke wijze wordt in het testproces rekening gehouden met informatiebeveiliging? Om deze vraag te kunnen beantwoorden is gekeken hoe de meest bekende en meest toegepaste testmethodieken, TMap Next en ISTQB, rekening houden met Security testing. In TMap Next voor resultaatgericht testen ( 5.2.4) wordt onder de afwijkingen die in de praktijk regelmatig voorkomen het volgende aangegeven: Security test, performance test, usability test Als een testvorm een zeer specifieke testomgeving of expertise behoeft, kan het zinvol zijn deze als aparte testsoort te organiseren, met een eigen plan en organisatie. Dergelijke tests worden daarom ook vaak uitbesteed. Daarnaast wordt bij de opsomming van de kwaliteitsattributen één korte alinea gewijd aan Beveiliging en wordt in 4.3 aangegeven wat per TMap Next fase aan security gedaan zou moeten worden. Het testen van de beveiliging van software in de betekenis van security testing krijgt in TMap Next echter géén aandacht en is dus ook niet terug te vinden in (sjablonen van) op TMap Next gebaseerde master en detail testplannen. ISTQB maakt in Advanced Level Syllabus (2007) onderscheid tussen functional security testing ( 5.2.4) en technical security testing ( 5.3.1). Verder wordt een aanpak voor het ontwerpen van security tests beschreven: Security Test Specification The following approach may be used to develop security tests. Perform information retrieval A profile or network map of the system is constructed using widely available tools. This information may include names of employees, physical addresses, details regarding the internal networks, IP-numbers, identity of software or hardware used, and operating system version. Perform a vulnerability scan The system is scanned using widely available tools. Such tools are not used directly to compromise the systems, but to identify vulnerabilities that are, or that may result in, a breach of security policy. Specific vulnerabilities can also be identified using checklists such as those provided at www.testingstandards.co.uk. Develop "attack plans" (i.e. a plan of testing actions intended to compromise a particular system's security policy) using the gathered information. Several inputs via various interfaces (e.g. user interface, file system) need to be specified in attack plans to detect the most severe security faults. The various "attacks" described in How to Break Software Security [James Whittaker and Herbert Thompson] (2004) are a valuable source of techniques developed specifically for security testing. 3.2 Gewenste situatie ( Soll ). In IT-beveiligingstesten als onderdeel in IT-audits [3] wordt de voorkeur uitgesproken voor het gecombineerd uitvoeren van IT-audits en IT-beveiligingstesten.

Organisatie SYSQA B.V. Pagina 8 van 25 De expertisegroep is van mening dat het testen van de beveiliging van software deel dient uit te maken van het testproces, dus gecombineerd dient te worden met elke test, ongeacht de toegepaste methode en testsoort. In het MTP en DTP dient daaraan invulling te worden gegeven als aanvulling op de verschillende testsoorten. In het hele proces van het definiëren van de Requirements van te ontwerpen en bouwen systemen tot en met de inproductiename van deze systemen dient dit item de nodige aandacht te krijgen. In Informatiebeveiliging voor requirementsanalist [4] wordt aandacht besteed aan de wijze waarop bij de formulering van requirements rekening kan worden gehouden met de beveiliging van het te ontwerpen systeem, terwijl Informatiebeveiliging voor functioneel beheer [5] aangeeft hoe de beheerders het na de inproductiename van het systeem dienen te doen. Onderstaand wordt aangegeven wat de testmanager of testcoördinator dient te doen om in het testtraject rekening te houden met beveiligingsaspecten. Het testen van de beveiliging dient één van de doelen te zijn bij het vaststellen van de opdracht en het beschouwingsgebied. Daartoe dient de testbasis tenminste uit de volgende belangrijke documenten te bestaan: Documentatie rondom wet en regelgeving (bijvoorbeeld SOX); De voor het te testen systeem geformuleerde requirements t.a.v. Beveiliging; De overige requirements; hierin kunnen zaken zitten die wel relevant zijn voor de beveiliging van het te testen systeem). Het beveiligingsbeleid van de organisatie van de opdrachtgever; Het functioneel ontwerp (beveiligingsonderdelen of juist ontbrekende onderdelen); Het technisch ontwerp; voor een test van beveiliging is hier veel waardevolle informatie uit te halen. De testmanager/testcoördinator dient erop toe te zien dat de opdrachtgever het testen van de beveiliging minstens even belangrijk vindt als het testen van de functionaliteit. Bij definiëren van de organisatie dient te worden gedacht aan personeel met de nodige kennis en ervaring voor het uitvoeren van de activiteiten ter beoordeling van de mate waarin aan de beveiligingseisen wordt voldaan. In deze testorganisatie mag een zogenaamde ethical hacker voor het uitvoeren van de penetratietest, die gericht is op het vinden van gaten in de beveiliging van het systeem, niet ontbreken. Een ethical hacker is een computer- en netwerkexpert die in opdracht van de eigenaar(s) de beveiliging van een system op de proef stelt, op zoek naar zwakke plekken die door kwaadwillende hackers kunnen worden geëxploiteerd. Bij het definiëren van de infrastructuur dient rekening te worden gehouden met het feit dat voor het testen van de beveiliging van een systeem het noodzakelijk is dat de tester meer controle heeft over de testomgeving dan bij andere testactiviteiten. De tester moet namelijk in staat zijn op een groter detailniveau de interacties van de software in de omgeving te bestuderen en te manipuleren, in zijn/haar zoektocht naar zwakke plekken in de beveiliging die door een hacker kunnen worden gebruikt. Interacties waaraan kan worden gedacht zijn: Gebruikersinteracties; Interacties met het file systeem; Interacties met het geheugen; Interacties met het besturingssysteem via system calls ; Interacties met andere componenten van hetzelfde systeem; Interacties met dlls (dynamically linked libraries); Interacties met andere software via apis; Interacties met andere software via interproces communicatie;

Organisatie SYSQA B.V. Pagina 9 van 25 Interacties met omgevingsvariabelen en de registry ; Interacties met het netwerk; Interacties met fysieke apparaten. De tester moet ook controle hebben over deze interacties. De testomgeving dient geïsoleerd te zijn, zodat kan worden voorkomen dat de resultaten van eventueel gelijktijdig uitgevoerde tests negatief worden beïnvloed door de uitgevoerde beveiligingstest. Ook dient de testmanager/testcoördinator acceptatiecriteria te (laten) definiëren voor de beveiliging van het te testen systeem. De beveiliging dient bij de uitvoering van de productrisicoanalyse (pra) ook op de agenda te staan. De in ISO25010 genoemde kwaliteitsattributen dienen in de pra te worden opgenomen. In de activiteitenplanning dient ruimte te worden gereserveerd voor de voorbereiding en uitvoering van de securitytest, het beoordelen van de resultaten daarvan en het hertesten van de oplossing van eventuele bevindingen. Bij het maken van het testontwerp dienen de volgende punten in overweging te worden genomen: De kans dat een gebeurtenis zich voordoet; Het risico dat de gebeurtenis met zich meebrengt wanneer het zich voordoet. Voor het testen van de beveiliging van het systeem kan het beste white box security testing (WBST) worden toegepast. Dat is een aanpak voor het verifiëren of de code conform het ontwerp is geïmplementeerd, het valideren van de geïmplementeerde beveiligingsfunctionaliteit, en het blootleggen van zwakke plekken die eventueel door hackers kunnen worden gebruikt. In bijlage 2 is een artikel opgenomen, waarin kort wordt ingegaan op deze aanpak. In hoofdstuk 2 is een tabel opgenomen, waarin is te zien welke activiteiten in het kader van het testen van beveiliging kunnen worden uitgevoerd in de verschillende fasen van de levenscyclus van software. Tevens is het van belang in de verschillende testfasen rekening te houden met de beveiligingsaspecten die van toepassing zijn op het te testen systeem. Onderstaand wordt per fase een indruk gegeven van de aspecten waarmee de testmanager of testcoördinator rekening dient te houden. Ook de gang van zaken na de inproductiename van het systeem wordt kort belicht. 3.2.1 Unit test Bij het plannen van de unit test dient men voor wat betreft de beveiliging de mogelijke dreigingen van toepassing op de componenten niet te onderschatten. Men moet in gedachte houden dat de hacker anders tegen de software omgeving aan kijkt dan de gewone gebruiker. M.a.w.: de hacker kan in staat zijn de software op manieren te gebruiken waarop de normale gebruiker het niet kan.

Organisatie SYSQA B.V. Pagina 10 van 25 Voorbeeld: Als een component gegevens leest uit een bestand, is het handig dat dit component voorziet in validatie van die gegevens, er vanuitgaand dat een hacker deze gegevens corrupt kan hebben gemaakt. Als in een component aannames worden gedaan over de invoer van gebruikers is het, ook al wordt deze invoer elders gecontroleerd, handig de aannames in dit component te valideren, omdat deze aannames het best begrepen worden door de ontwikkelaar(s) van die component. Het lokaal controleren van zulke aannames maakt onderhoud, ingeval van wijziging van deze aannames, simpeler. Bij het evalueren van potentiële bedreigingen van een software component dient in gedachte te worden gehouden dat vele aanvallen bestaan uit twee stappen: In de eerste stap verkrijgt de hacker op afstand toegang tot de machine; In de tweede stap neemt de hacker, na het verkrijgen van toegang, de controle over de machine. Voorbeeld: Een hacker die zich toegang heeft weten te verschaffen tot een webserver beschikt eerst over de privileges van die server. Daarmee is hij in staat een aantal lokale aanvalsstrategieën te gebruiken, zoals het corrupt maken van systeembronnen en het uitvoeren van programma s met speciale privileges in corrupte omgevingen. Het is het daarom een vereiste dat lokale dreigingen worden vastgesteld en maatregelen worden getroffen op: Systemen waarvan wordt aangenomen dat er geen ongewenste gebruikers toegang hebben; Systemen waartoe menselijke gebruikers helemaal geen toegang horen te hebben. 3.2.2 Testen van bibliotheken en uitvoerbare bestanden Bibliotheken (Libraries) verdienen ook speciale aandacht bij het testen van de beveiliging. Componenten die deel uitmaken van een bibliotheek kunnen eventueel worden hergebruikt op manieren waar in het huidig ontwerp geen rekening mee is gehouden. Bij het testen van bibliotheken dient het volgende in gedachte te worden gehouden: 1. Dat een bibliotheekfunctie in het huidig ontwerp beschermd wordt door andere componenten, wil nog niet zeggen dat deze in de toekomst ook beschermd zal zijn. Voorbeeld: Een buffer overflow in een bepaalde bibliotheekfunctie lijkt misschien weinig risico met zich mee te brengen, omdat hackers geen controle kunnen krijgen over de gegevens die door deze functie worden verwerkt, maar in de toekomst kan deze functie worden hergebruikt op een manier die het toegankelijk maakt voor hackers. 2. Verder kunnen bibliotheken worden hergebruikt in toekomstige software ontwikkelingsprojecten, ook al is daar bij het ontwerpen van het huidige systeem geen rekening mee gehouden. Dat brengt additionele problemen met zich mee: Het kan voorkomen dat de ontwikkelaars van de code niet meer beschikbaar zijn en de code niet meer zo goed als toen wordt begrepen. Bij hergebruik van deze code dient de initiële beveiligingstest grondig te worden uitgevoerd. Zwakke plekken in de bibliotheek hebben een grotere negatieve impact wanneer de bibliotheek in meerdere systemen is gebruikt;

Organisatie SYSQA B.V. Pagina 11 van 25 Indien veelvuldig gebruikt kunnen hackers vertrouwd raken met de zwakke plekken en oplossingen hebben bedacht om deze uit te buiten. Dat maakt een audit en test van de bibliotheekfuncties in een vroeg stadium ontzettend belangrijk. 3.2.3 Integratietest Bij de integratietest is de aandacht gevestigd op een verzameling subsystemen, die kunnen bestaan uit vele uitvoerbare componenten (executables). Vele onregelmatigheden doen zich voor als gevolg van de manier waarop componenten met elkaar communiceren. Fouten bij de integratie zijn vaak het resultaat van onterechte aannames van het ene subsysteem t.o.v. het andere. Een simpel voorbeeld van een integratiefout doet zich voor wanneer bibliotheekfuncties worden aangeroepen met argumenten die een verkeerd datatype hebben. In de programmeertaal C, bijvoorbeeld, hoeft er geen waarschuwing te zijn afgegeven door de compiler, wanneer een waarde van het type integer wordt doorgegeven, terwijl er een waarde van het type unsigned integer wordt verwacht. Dit kan een negatief getal wel veranderen in een groot positief getal. Dit kan zorgen voor een zwak punt in de beveiliging wanneer de variabele in kwestie gebruikt wordt als een bufferlengte. Zo kan elke controle door de aanroepende functie worden ontdoken. Een integratiefout kan zich ook voordoen wanneer de aanroepende functie en de aangeroepen functie aannemen dat de andere functie verantwoordelijk was voor controles en geen van beide de controle uitvoert. In feite is het niet of slecht controleren van invoerwaarden één van de meest voorkomende zwakke punten in software. Integratiefouten zijn de meest voorkomende bronnen van niet gecontroleerde invoerwaarden, omdat elke component kan aannemen dat de controle elders wordt uitgevoerd. Alle componenten dienen hun eigen data te valideren, maar in veel systemen wordt dit in verband met efficiency opgeofferd. Tijdens het testen van de beveiliging is het van groot belang vast te stellen welke gegevens kunnen worden beïnvloed door een hacker. Software ten behoeve van foutafhandeling kan ook integratiefouten veroorzaken door ongebruikelijke controle en data flow patronen tijdens de foutafhandeling. Foutafhandeling is ook een vorm van interactie tussen componenten, die tijdens de integratietest aandacht dient te krijgen. 3.2.4 Systeemtest In de latere stadia van het ontwikkelingsproces komt het hele systeem ter beschikking voor de test. Deze testfase kan bestaan uit integratietesten en functioneel testen, maar wordt apart behandeld omdat het hele systeem kan worden aangevallen. Verder worden bepaalde activiteiten die te maken hebben met het testen van beveiliging, zoals een stress test, meestal op systeemniveau uitgevoerd. Hoewel de aanval gericht is op het complete systeem, kan een aanvaller individuele componenten gebruiken wanneer hij/zij eenmaal toegang heeft gekregen tot een lokale machine. Om die toegang te verkrijgen dient de hacker eerst controle te krijgen over een extern gericht software systeem. Een voorbeeld van een dergelijk systeem is een systeem dat voorziet in sommige netwerkdiensten en daardoor toegankelijk is voor de hele wereld. Er zijn ook gevallen waarin een hacker gedwongen wordt het gevecht aan te gaan met een compleet software systeem. Zo kan een hacker die zich in een beschermd domein bevindt een ander domein aanvallen. Een hacker die één laag van het besturingssysteem onder controle heeft kan ook een andere laag van het besturingssysteem aanvallen. Uit oogpunt van beveiliging is het een vereiste dat individuele uitvoerbare programma s veilig zijn, maar op systeemniveau zijn rigoureuze beveiligingsmaatregelen vereist om te

Organisatie SYSQA B.V. Pagina 12 van 25 voorkomen dat hackers een steunpunt kunnen vinden, van waaruit ze aanvallen kunnen voorbereiden/uitvoeren. 3.2.5 Penetratietesten. Een penetratietest of pentest is een check van één of meer computersystemen op kwetsbaarheden, waarbij deze kwetsbaarheden ook werkelijk gebruikt worden om op deze systemen in te breken. De penetratietest heeft tot doel te testen hoe moeilijk het is om een computernetwerk of een systeem ongeautoriseerd binnen te dringen. Daarbij wordt gebruik gemaakt van softwaretools om gaten in de beveiliging (vulnerabilities) van netwerken en systemen te ontdekken. Deze test wordt, in tegenstelling tot voorgaande testfasen, uitgevoerd in een omgeving die bijna een kopie is van de productieomgeving en waarin alle eventueel in eerdere testfasen gebruikte stubs zijn vervangen door de programmatuur die voorziet in de noodzakelijke functionaliteit. Een penetratietest vindt normaal gesproken om legitieme redenen plaats, met toestemming van de eigenaars van de systemen die gecheckt worden, met als doel de systemen juist beter te beveiligen. Indien het niet om legitieme redenen plaatsvindt, zonder toestemming van eigenaars van systemen is er sprake van een inbraak, zelfs als de intentie van de persoon die de test uitvoert constructief is. De persoon die een penetratietest uitvoert heet wel een penetratietester of pentester of white hat hacker. Een penetratietest kan handmatig plaatsvinden, met gebruik van softwareprogramma s zoals nmap en telnet, of het kan geautomatiseerd plaatsvinden met softwarepakketten die dit soort complete penetratietests kunnen uitvoeren. Voorbeelden van dit soort pakketten zijn Nessus, OpenVas, Retina, SecPoint, GFI Languard, Core Impact en SAINT. Er kunnen diverse soorten penetratietests worden onderscheiden, de white box penetratietests, ook wel white box pentest genoemd, of de black box penetratietests, ook wel black box pentest genoemd. In het eerste geval krijgt de pentester voor het testen al informatie over het netwerk of de computer die getest wordt, in het laatste geval juist niet. White box penetratietests vinden vaak plaats indien men het eigen personeel ervan verdenkt, eigen systemen te hacken. Bij black box penetratietest wordt meer uitgegaan van de positie van de externe computerkraker, die zonder vooraf kennis te hebben van vertrouwelijke informatie over een organisatie zijn pogingen tot het kraken van systemen zal uitvoeren. De penetratietest wordt ook op systeemniveau uitgevoerd. Zwakke punten die tijdens deze test worden blootgelegd zijn het tastbaar bewijs dat het systeem niet goed genoeg beveiligd is om hackers op een afstand te houden. Dit zijn de meest belangrijke zwakke punten die dienen te worden weggewerkt. Ze dienen door de ontwikkelaars serieus te worden genomen. Een verschil tussen een penetratietest en een audit (beveiligingscontrole) is, dat bij een audit geen poging wordt gedaan om daadwerkelijk in te breken, maar enkel mogelijke kwetsbaarheden in kaart gebracht worden. Bij een penetratietest worden kwetsbaarheden juist wel gebruikt om in te breken. 3.2.6 Stress test Een stresstest is een testvorm waarbij de stabiliteit van een geheel wordt getest. Hierbij wordt getest met een zwaardere belasting dan gebruikelijk, vaak tot het punt dat het systeem het begeeft. Het doel hiervan is te onderzoeken wat er gebeurt en waar de grens ligt.

Organisatie SYSQA B.V. Pagina 13 van 25 Bij het testen van software wordt met een "systeem stresstest" een test bedoeld waarbij getest wordt op zaken als robuustheid, beschikbaarheid en foutafhandeling bij zware belasting. Het doel van deze tests is na te gaan of de software niet crasht als gevolg van bijvoorbeeld een gebrek aan systeembronnen, zoals RAM-geheugen, opslagcapaciteit, ongebruikelijke aantallen gelijktijdige gebruikers of denial-of-service aanvallen. Voorbeeld: Een webserver kan een stresstest ondergaan met behulp van scripts, bots, en verschillende denial-of-service programma's, waarmee de performance van een website onder piekbelasting wordt getest. Er zijn verschillen tussen een belastingstest en stresstest. Het belangrijkste verschil zit in het doel van de test. Bij een belastingstest wordt het gehele systeem getest, inclusief de database, waarbij de reactietijd gemeten wordt, terwijl bij een stresstest geconcentreerd wordt op enkele transacties die dan tot de grens belast worden, totdat het systeem crasht. Het kan gebeuren dat bij een stresstest de specifieke transacties of onderdelen getest worden terwijl de database dit gemakkelijk aankan. Aan de andere kant wordt bij een belastingstest de database zwaar belast terwijl de transacties het eenvoudig aankunnen. Een populaire stresstest is het laden van meer dan het maximale aantal concurrentgebruikers, zodat het systeem dan crasht bij de zwakste schakel. Hierdoor wordt duidelijk wat de zwakste schakel is en waar de grens van de belastbaarheid van het systeem ligt. De stresstest is ook relevant bij het testen van de beveiliging, omdat software zich onder stress anders gedraagt. Wanneer een component vanwege onvoldoende bronnen buiten werking is, kunnen andere componenten dit tekort op onveilige wijze compenseren. Een uitvoerbaar programma kan bij een crash tijdens de uitvoering gevoelige informatie achterlaten op plaatsen die toegankelijk zijn voor hackers. Hackers kunnen in staat zijn trage of buiten werking zijnde subsystemen te foppen (spoofing), waardoor ze gemakkelijker uit te buiten zijn. Stresstesten kunnen ook bijdragen bij het trainen van programmatuur t.b.v. foutafhandeling. Beveiligingstesters dienen tijdens de stress test ook te letten op ongebruikelijk gedrag dat een signaal kan zijn voor de aanwezigheid van onverwachte zwakke plekken. Tijdens de stress test worden componenten geacht bestand te zijn tegen onverwachte situaties, maar veel zwakke plekken komen boven water door condities die de ontwikkelaars niet hebben verwacht. Het belang van functioneel testen en integratietesten mag men niet onderschatten. Tijdens voorgaande testfasen kunnen sommige componenten zijn vervangen door één of meerdere stub(s), maar in de fase van functioneel en integratietesten dient het systeem datgene te doen dat het na de inproduktiename dient te doen. 3.3 Toepassen van reviewtechnieken Vroeg betrokken zijn in het project betekent ook dat de tester van beveiliging een toetsende rol in kan nemen. Door vroeg in het project betrokken te raken zijn fouten al vroeg op te sporen. Een maatregel ter verhoging van de kwaliteit van de ontwikkelde producten is code review. Beveiliging is een wezenlijk onderdeel van kwaliteit en dient dus in die hoedanigheid te worden getoetst. Bij een code review scant een persoon (anders dan de ontwikkelaar) of een programma de programmacode op mogelijke kwetsbaarheden. Deze aanpak, ook wel een whitebox scan of statische analyse genoemd, kan problemen aan het licht brengen die men via een blackbox scan niet zal ontdekken. Beter nog is het om de code review in verschillende

Organisatie SYSQA B.V. Pagina 14 van 25 stadia van het ontwikkelproces uit te voeren om op die manier fouten in een vroeg stadium en dus vaak gemakkelijker, te kunnen verhelpen. Een code review vergt over het algemeen meer inspanning dan een blackbox scan. Tools voor het uitvoeren van geautomatiseerde code reviews bestaan er in vele soorten en maten, van opensource software tot prijzige commerciële toepassingen. Onderstaande - niet uitputtende - lijst geeft enkele punten weer waarop een geautomatiseerde tool kan controleren: Het afvangen van excepties; De mogelijkheid tot het genereren van buffer overflows; De aanwezigheid van type mismatches; Gebruik van potentieel gevaarlijke functies; Juiste toepassing van invoervalidatie; Datastromen door een webapplicatie. Het code review proces bestaat uit een aantal stappen die onderstaand specifiek toegespitst zijn op het toetsen van beveiliging. Het toetsen is een statische activiteit en vindt al vroeg in het ontwikkelproces plaats. De review kan starten als stukjes code (units) gereed zijn. Vaak is dit op het moment dat de unit test plaatsvindt. De volgende stappen zijn onderdeel van het proces: 1. Verzamelen van documentatie. Welke standaards en best practices rondom beveiliging zijn er voor de ontwikkelaars? Deze worden vaak opgelegd door de organisatie en beschrijven een manier voor het veilig ontwikkelen van software. Welke projectdocumentatie is er en waar beschrijft deze de beveiliging? Als tester van beveiliging kun je bij het ontbreken hiervan navraag doen in de organisatie waarom ze er niet zijn en de noodzaak inzichtelijk maken. Het ontbreken ervan betekent niet dat de volgende stappen niet uitgevoerd kunnen worden. 2. Is het product (productonderdeel) gerealiseerd conform de opdracht? Zijn de in de projectdocumentatie gestelde beveiligingseisen juist, volledig en aantoonbaar gerealiseerd? Rondom beveiliging is dit essentieel. Als namelijk één van de eisen niet geïmplementeerd is, kan dit grote impact hebben op de keten van beveiliging. Het komt voor dat bepaalde eisen niet geïmplementeerd zijn, hiervoor moet dan een andere oplossing aanwezig zijn. 3. Voldoet het product aan de volgende criteria: intern consistent, conform standaards en best practices en de best mogelijke beveiligingsoplossing? In deze stap zijn de standaards en best practices vanuit stap 1 de richtlijn voor de toetsing. Zijn deze gebruikt en correct toegepast? Bij de best mogelijke beveiligingsoplossing is er meestal een spanningsveld. Soms komt beveiliging gebruiksvriendelijkheid niet ten goede. Afhankelijk van het type applicatie en de risico s die er mogen zijn, moeten er keuzes gemaakt worden. Een interne applicatie zonder bedrijfskritische gegevens kan anders omgaan met beveiliging dan een online verzekeraar met toegang tot alle persoonsgegevens. 4. Draagt het product bij aan de project- en architectuurdoelstellingen? De consistentie met andere (deel)producten is hier van belang evenals de connecties naar andere producten. Hierbij moet eveneens gelet worden op beveiliging. Voor het in kaart brengen van de architectuur is tooling te gebruiken. Deze doorloopt de software en brengt de paden en afhankelijkheden van de componenten in beeld. 5. Is het product geschikt voor gebruik in de volgende fase van ontwikkeling? Moeten de gebruikte standaards en richtlijnen rondom beveiliging worden aangepast? Het kan voorkomen dat doordat de techniek zich verder ontwikkelt er nieuwe bedreigingen bij gekomen zijn. Net als verandering van inzicht kan dit ertoe leiden dat de in stap 1 verzamelde standaards niet meer voldoen. Het is zaak deze dan aan te passen. Daarnaast vindt in deze stap de evaluatie plaats op de voorgaande stappen en kan er besloten worden de software niet mee te nemen, opnieuw te ontwikkelen of het juist opnieuw te gebruiken.

Organisatie SYSQA B.V. Pagina 15 van 25 3.4 Testen met Abuse cases In 2.1. is aangegeven dat naast een review van de requirements ook een review van use cases en abuse cases dient te worden uitgevoerd. Om het testen met abuse cases mogelijk te maken is het van belang dat het FO naast use cases ook abuse cases beschrijft. Een use case is een beschrijving van de interactie tussen een systeem en een of meerdere actors. Hierin is vaak goed en nauwkeurig beschreven wat een gebruiker mag doen en met welke rechten. Een abuse case is een beschrijving van de interactie tussen een systeem en één of meerdere actors, waarbij de uitkomst van de interactie schadelijk is voor het systeem, een actor of een of meerdere stakeholders van het systeem. Meestal is in een ontwikkeltraject alleen aandacht voor de use case en niet voor de abuse case. Als de taak van de tester het testen van beveiliging is en er zijn geen abuse cases beschikbaar, dan kan de tester zelf de abuse cases maken of via de testmanager/testcoördinator deze alsnog laten beschrijven. In onderstaand schema Abuse case testing is een abuse case in kaart gebracht. Hierin is te zien dat er een actor is maar ook een hacker (kwaadwillend). Eveneens is in dit schema een mogelijke oplossing opgenomen. Abuse case testing Het doel van abuse cases is het leren denken als een hacker en misbruik in kaart brengen. Abuse cases maken het begrijpen van de mogelijke beveiligingsissues voor gebruikers zonder beveiligingskennis makkelijker en laten de applicatie zien vanuit het oogpunt van een hacker. Een abuse case geeft een beeld van een range van verschillende mogelijke beveiligingsissues. Daarnaast is de oplossing voor mogelijke bedreigingen al vroeg in kaart te brengen en dus ook mee te nemen in het ontwikkelproces. Aan de hand van beveiligingsrequirements kunnen abuse cases worden samengesteld. Als deze echter niet voor handen zijn, zullen ze ontwikkeld moeten worden. Abuse case testing is erg goed toe te passen als er al gebruik gemaakt is van use case testing. Een abuse case kan in een afbeelding samen komen met de use case. Hierdoor is het testen van beveiliging niet meer een losstaand iets, maar kan het worden meegenomen in de gewone test die moet worden uitgevoerd.

Organisatie SYSQA B.V. Pagina 16 van 25 3.5 Tooling Tooling is één van de zaken die bij het testen van beveiliging onmisbaar is. Als er een beveiligingstest moet worden uitgevoerd is specifieke tooling noodzakelijk, bijvoorbeeld bij het onderscheppen van het berichtenverkeer. De tooling voor het testen van beveiliging is op te delen in een aantal verschillende categorieën. Het is van belang het onderscheid hiertussen te kennen zodat de tooling op een juiste wijze is in te zetten. Onderstaand worden enkele voorbeelden genoemd. Per tool is aangegeven wat de tool doet en daarbij waarvoor het te gebruiken is. Naast deze tooling bestaan er nog vele soorten en varianten. Daar wordt in document niet op ingegaan. - Proxyserver: dit is een server (in een tool) die zich bevindt tussen de computer van de gebruiker (client) en de computer waar de informatie vandaan komt (server). Bij het testen van beveiliging is de webproxy (dit is een vorm van een proxyserver) in te zetten om de data te onderscheppen en aan te passen voordat het daadwerkelijk naar de server gaat. Er zijn veel freeware of open source webproxy te vinden op het internet. - Static code analysis tooling (statische code analyse): met dit type tool kan de broncode geanalyseerd worden zonder dat daarvoor het programma hoeft te draaien. De tool zoekt mogelijke kwetsbaarheden op in de code. Deze kwetsbaarheden kunnen daarna handmatig (als het programma onderdeel gebouwd is) getest worden en dienen dan als input voor de penetratietest. - Dynamic program analysis (dynamische programma analyse): met dit type tool kan een programma dat reeds gebouwd is geanalyseerd worden. Dit tool is later in de tijd in te zetten dan de statische tooling. Dit type tooling geeft eveneens mogelijke kwetsbaarheden in de applicatie aan. Handmatig is verder onderzoek nodig om te valideren of deze kwetsbaarheden daadwerkelijk gaten in de beveiliging zijn. - Bevindingenbeheertool voor het loggen en afhandelen van bevindingen. Let hierbij op dat dit een tool moet zijn die goede functionaliteiten biedt om beveiligingsincidenten af te schermen voor mensen die er niets mee te maken hebben. - Overig: er zijn vele kleine tools ter ondersteuning van het testen van beveiliging, bijvoorbeeld voor het automatisch detecteren van een SQL-injection punt, het scannen van het netwerkverkeer en het decoderen van een Base64 codering. Bij tooling is het belangrijk dat men zich constant realiseert dat tooling ter ondersteuning is en de structurele aanpak en het menselijk brein noodzakelijk zijn. De tooling is ter ondersteuning maar zeer zeker niet te missen. 3.6 De operationele fase De operationele fase van de software life cycle begint bij de uitrol van de software. De software is niet meer in handen van de ontwikkelaars of de testers. Traditioneel wordt de bêta-test geassocieerd met de vroege operationele fase. Bêtatesten heeft zijn tegenhanger in de beveiligingsarena, omdat white-hat hackers kunnen zoeken naar zwakke plekken in de software. White-hat hackers zijn hackers die een computer hacken zonder de bedoeling schade aan te richten of informatie te stelen, maar om de gebruikers er op te wijzen dat er beveiligingsproblemen zijn. Het is echter ook mogelijk dat zwakke plekken ontstaan na de uitrol, door configuratiefouten of onvoorziene factoren in de productieomgeving. Bij het uitvoeren van updates van individuele componenten kunnen ook zwakke plekken ontstaan in een bestaand systeem, omdat aannames die tijdens de ontwikkeling van die component valide waren niet meer valide zijn na de uitrol van de nieuwe versie.

Organisatie SYSQA B.V. Pagina 17 van 25 Het kan ook voorkomen dat sommige componenten een update ondergaan en sommige niet, waardoor een melange van software versies ontstaat waarvan de exacte samenstelling niet kan worden voorzien in welke manier van ontwikkelen dan ook. Daardoor zijn de kwetsbaarheden van het samengestelde systeem ook niet te voorzien. Sommige subsystemen kunnen ook op de locatie zijn aangepast, waardoor het nog moeilijker wordt om een totaal overzicht van het systeem en de potentiële kwetsbaarheden te behouden. Het risicoprofiel van het systeem kan ook in de loop van de tijd veranderen, waardoor het noodzakelijk wordt voortdurende controles op de veiligheid uit te voeren op de systemen die in productie zijn. Dit kan gebeuren wanneer het systeem wordt gebruikt op manieren waarin niet is voorzien tijdens de ontwikkeling, of wanneer het relatieve belang van de verschillende activa groeit of afneemt. Zo kan een organisatie onbewust kritieke informatie beschermen met encryptie-methoden die niet meer als veilig worden beschouwd. Het risicoprofiel kan ook veranderen als nieuwe kwetsbaarheden zijn ontdekt in bestaande software versies. In feite kunnen er geheel nieuwe klassen van kwetsbaarheden zijn die niet waren voorzien tijdens de ontwikkeling. Er is bijvoorbeeld sprake van een format string kwetsbaarheid wanneer een hacker het eerste argument van een print-statement in de programmeertaal C / C++ onder controle kan krijgen. Voordat ze werden erkend als kwetsbaarheden, was het moeilijk voor te stellen hoe een ontwikkelinginspanning, hoe zorgvuldig deze ook moge zijn, ze systematisch zou kunnen vermijden. Het gevaar van een eenvoudige opdracht, zoals print(working_directory) werd gewoon niet herkend. In het algemeen zijn hackers kort na het ontdekken van kwetsbaarheden op de hoogte van het bestaan daarvan. Een verantwoordelijke ontwikkelingsorganisatie brengt dan een patch uit, maar gebruikers kunnen afzien van het installeren van die patch in hun omgeving. Dit creëert een drastische verschuiving in het risicoprofiel van het systeem. Een hiermee samenhangend vraagstuk is dat encryptietechnieken die worden gebruikt door een systeem verouderd kunnen zijn, hetzij, omdat steeds meer rekenkracht het mogelijk maakt encryptiesleutels te kraken, of omdat onderzoekers verschillende manieren hebben ontdekt om encryptieschema s waarvan eerder werd gedacht dat ze veilig waren, te kraken. Deze kwesties creëren de behoefte aan security audits in productiesystemen. Idealiter worden de audits uitgevoerd door security professionals. Vele testactiviteiten, vooral die in het kader van de systeemtest kunnen hierbij ook nuttig zijn. Helaas bestaan security audits vaak uit checklists en scans door geautomatiseerde tools. Dit maakt een kritische opmerking bij de discussie over het testen van beveiliging in de levenscyclus van de software noodzakelijk. Maar al te vaak hebben organisaties te veel vertrouwen in zwakke, geautomatiseerde testtools als enig middel voor het uitvoeren van security audits. Dergelijke testtools voeren meestal een reeks ingebouwde testen uit die bekende aanvallen simuleren, maar controleren ook softwareversies en voeren andere controles uit die niet direct betrekking hebben op pogingen het systeem te penetreren. Deze instrumenten hebben hun plaats, maar ze moeten niet het enige middel van het handhaven van de veiligheid in een systeem zijn.

Organisatie SYSQA B.V. Pagina 18 van 25 4 Tenslotte In voorgaande paragrafen van dit hoofdstuk is beschreven waarmee rekening dient te worden gehouden wanneer het testen van de beveiliging wordt opgenomen in het gebruikelijke testtraject. Het is geen volledige opsomming, maar kan nuttig zijn voor testmanagers of testcoördinatoren die te maken krijgen met systemen waar beveiliging van groot belang is, of in een situatie belanden waarin de opdrachtgever overtuigd moet worden van het belang van het uitvoeren van een beveiligingstest. Ook testers kunnen er hun voordeel mee doen. De gebruikte voorbeelden geven een indruk van de wijze waarop door hackers kan worden getracht toegang te krijgen tot een systeem en hoe een tester zich daarop kan voorbereiden. Daarnaast is een indruk gegeven van de verschillen tussen het testen van de beveiliging van systemen en het testen van systemen zonder aandacht voor de beveiliging van deze systemen. Rekening houden met alle in dit document en in overige vakliteratuur beschreven technieken, die door hackers worden toegepast, draagt bij tot een degelijke voorbereiding en uitvoering van de beveiligingstest. Voor richtlijnen voor het verifiëren van de beveiliging van de operationele applicaties wordt verwezen naar versie 3 van de Testing Guide [6] van de OWASP (The Open Web Application Security Project). Tenslotte is in bijlage 1 de OWASP Testing Checklist opgenomen. Deze checklist geeft aan waar bij het uitvoeren van een security test op dient te worden gelet en is in de vorm van een Excel spreadsheet te vinden op https://code.google.com/p/owasptesting-checklist/.

Organisatie SYSQA B.V. Pagina 19 van 25 5 Bijlage 1. OWASP Testing Checklist The following is the list of controls to test during the assessment: Information Gathering OWASP-IG- 4.2.1 Spiders, Robots and Crawlers N.A 001 OWASP-IG- 4.2.2 Search Engine N.A. 002 Discovery/Reconnaissance OWASP-IG- 4.2.3 Identify application entry points N.A. 003 OWASP-IG- 4.2.4 Testing for Web Application N.A 004 Fingerprint OWASP-IG- 4.2.5 Application Discovery N.A. 005 OWASP-IG- 006 4.2.6 Analysis of Error Codes Information Disclosure Configuration Management Testing OWASP-CM-001 4.3.1 SSL/TLS Testing (SSL Version, SSL Weakness Algorithms, Key length, Digital Cert. Validity) OWASP-CM-002 4.3.2 DB Listener Testing DB Listener weak OWASP-CM-003 4.3.3 Infrastructure Configuration Management Testing Infrastructure Configuration management weakness OWASP-CM-004 4.3.4 Application Configuration Management Testing Application Configuration management weakness OWASP-CM-005 4.3.5 Testing for File Extensions Handling File extensions handling OWASP-CM-006 4.3.6 Old, backup and unreferenced files Old, backup and unreferenced files OWASP-CM-007 4.3.7 Infrastructure and Application Access to Admin interfaces Admin Interfaces OWASP-CM-008 4.3.8 Testing for HTTP Methods and XST HTTP Methods enabled, XST permitted, HTTP Verb Authentication Testing OWASP-AT-001 4.4.1 Credentials transport over an encrypted channel Credentials transport over an encrypted channel OWASP-AT-002 4.4.2 Testing for user enumeration User enumeration OWASP-AT-003 4.4.3 Testing for Guessable (Dictionary) Guessable user account User Account OWASP-AT-004 4.4.4 Brute Force Testing Credentials Brute forcing OWASP-AT-005 4.4.5 Testing for bypassing authentication schema Bypassing authentication schema OWASP-AT-006 4.4.6 Testing for vulnerable remember password and pwd reset Vulnerable remember password, weak pwd reset OWASP-AT-007 4.4.7 Testing for Logout and Browser Cache Management Logout function not properly implemented, browser cache weakness OWASP-AT-008 4.4.8 Testing for CAPTCHA Weak Captcha implementation OWASP-AT-009 4.4.9 Testing Multiple Factors Authentication Weak Multiple Factors Authentication