Pentest as a Service (PtaaS) hitter, men hvornår skal du vælge automatiseret vs manuel sikkerhedstest?

Manuelt arbejde har altid været en stor del af penetrationstest, fordi konteksten – måden som koden og funktionalitet er bygget op på i en specifik applikation – aldrig er helt ens. Det er muligt at automatisere dele af sikkerhedstesten, men der er nogle takeoffs som man skal være opmærksom på. I denne artikel afdækker vi forskellen og diskuterer i hvilke kontekster de to metoder hører hjemme.

Lad os starte med at give TL;DR-beskrivelsen: Automatisering er godt til at give en grundlæggende ide omkring sikkerheden i jeres systemer. Det er en nem og billig måde at verificere, om der er ”low-hanging-fruits” sårbarheder. Men det er typisk besværligt at finde mere komplekse og skjulte sårbarheder gennem automatisering. Værktøjerne mangler kontekst på applikationen og nødt til at afgrænse, hvor meget den undersøger, for at blive færdig med scanningen inden for et rimeligt tidsrum.

Pentestere der har erfaring med applikationstest kan afdække applikationen dybere, da de forstår konteksten af applikationen og har større intuition for hvilke dele af applikationen der kan være sårbare. F.eks. vil det være besværligt at finde frem til at en webshop lader brugerne definerer prisen på en vare, når de tjekker ud til betaling gennem automatisering, men en pentester kan forstå denne kontekst. Dog er tiden til at teste manuelt typisk begrænset, og det kan ske, at en pentester overser problemstillinger i applikationerne. Her har automatisering sin fordel. Generelt anbefaler vi, at man regelmæssig benytter de automatiserede værktøjer til at sikre sig at der ikke er ”low-hanging-fruits” sårbarheder, og derefter sørger for at få kritiske systemer tjekket igennem for sikkerheden via en manuel pentest.

Automatiseret scanning

Der findes mange forskellige løsninger angående automatisering af scanning for sårbarheder og fejlkonfigureringer. Disse varierer i hvor dybt kendskab de har til applikationen, hvilke sårbarheder de har mulighed for at teste efter, deres pris, og hvor nemme de er at benytte.

DAST (dynamic application security testing) værktøjer kan scanne i kørende tilstand. Disse er gode til at finde ”low-hanging fruit” sårbarheder, samt at teste for kendte udbredte sårbarheder. Dog er det sjældent at disse værktøjer er gode til at finde nye, relativt ukendte, sårbarheder i applikationer. Dette sker da mængden af tjek scanneren skal udføre stiger markant, hvis hele applikationen skal afdækkes. Derfor er de fleste DAST værktøjer nødt til at afgrænse sig til at teste en mere snæver del af applikationen. Vi benytter selv disse værktøjer som en del af flere services, og til at bidrage for manuelle pentests. Vores erfaring viser at værktøjerne er gode til at finde ”low-hanging fruits” fejlkonfigurationer, men det er sjældent disse der finder de kritiske sårbarheder under vores manuelle test.

SAST (static application security testing) værktøjer går et niveau dybere i en applikation, da disse tager udgangspunkt i kildekoden på applikationen når de analyserer applikationen. Ved at bruge disse værktøjer kan man blive gjort opmærksom på problemstillinger i ens applikation, der ikke er åbenlyse at finde frem til ved at analyserer applikationen i kørende tilstand uden kendskab til kildekoden. Vi anbefaler at man benytter et SAST-værktøj som en del af ens CI/CD-pipeline. Dette har to vigtige effekter på jeres applikation og virksomhed:

• Det sørger for at potentielle sårbarheder i applikationen bliver fjernet inden de bliver sat i produktionsmiljøet
• Det bidrager til at undervise udviklerne i at skrive sikker kode, da konkrete faldgrupper bliver highlightede på en løbende basis hvis udviklerne skriver usikker kode uden at være opmærksom på dette.

De store fordele ved automatisering er at der er et mindre krav til hvor meget manuel tid der skal investeres i at køre testen, dermed er det typisk billigere at benytte dette end at have en kvalificeret pentester til at analyserer applikationen. Med det sagt, eksisterer der sårbarhedskategorier som er meget svære at opdage gennem automatisering. Hele kategorien ”business logic issues” kræver at man forstår konteksten af applikationen. F.eks., hvis I har en webshop og lader kunden selv sende en forespørgsel til serveren om at købe nogle varer, hvor kunden også selv fortæller serveren hvor meget varerne koster. Det er svært for automatisering at forstå at det er et problem hvis kunden kan ændre prisen, men det kan være en meget kritisk sårbarhed hvis det først bliver opdaget efter flere kunder har misbrugt det.

Manuel pentest

Ved manuel pentest er det en person der manuelt prøver at finde og udnytte eventuelle sårbarheder i applikationen. Dette kan være en af udviklerne af applikationen, med teknisk viden inden for opbygningen af applikationen, eller en pentester med viden og erfaring inden for de forskellige faldgrupper i applikationer der leder til sårbarheder.
Målet er at spotte og bevise eventuelle sårbarheder i applikationen der kan være af en mere kompleks art, samt at afdække problemstillinger der ikke er nemme at afdække automatisk. Sådanne problemstillinger kan være business logic problemer, hvor man misbruger funktionalitet i applikationen på en måde der ikke er tiltænkt, samt problematikker angående implementeringen af rettighedssystemet der sikrer at brugerne ikke kan tilgå hinandens data.

Man kan opdele pentest i forskellige kategorier afhængig af hvor meget information og adgang pentesteren har i forhold til applikationen. En black-box test vil typisk foregå med adgang til applikationen som en almindelig bruger, uden nogen form for adgang og kendskab til applikationens infrastruktur og kode. Ved en white-box test afdækkes det samme som ved en black-box test, forskellen er typsik at pentesteren har adgang til at se applikationens kildekode og snakke med udviklerne bag applikationen. Dette giver mulighed for at lave en mere dybdegående test, og giver pentesteren mere kontekst på eventuelt skjult funktionalitet, obskure API endpoints og parametre der ikke nødvendigvis bliver benyttet ved almindelig brug af applikationen. Produktet af black- og white-box pentest er typisk en rapport der highlighter eventuelle problemer, viser et eksempel på hvordan de kan udnyttes, samt kommer med anbefalinger til hvordan man kan udbedre problemstillingerne. Ved en ”purple team applikationspentest” går pentesteren, der også har dyb viden inden for softwareudvikling og -arkitektur, ind og i et større omfang og arbejder sammen med udviklingsholdet om at designe og implementerer eventuelle løsninger på problemstillingerne. Pentesteren er også regelmæssigt med i udviklingsprocessen for at sikre at sikkerhed bliver tænkt med fra start.

Ved manuelle pentests er det, afhængig af tid og scoping, typisk en bred vifte af problemstillinger i applikationen der bliver testet for. Dette omhandler alt fra om applikationen gør brug af browserens standard sikkerhedsmekanismer, til om man kan sammensætte et specielt input i en form så man kan læse og ændre hele applikationens database. Mange pentestere, ReTest Security inklusiv, tager udgangspunkt i brede testplaner der er defineret af standard- og industriorganisationer. Hos ReTest Security tager vores webapplikations pentest udgangspunkt i OWASP Web Security Testing Guide (WSTG), hvor vi har udbygget testplanen til at afdække flere testcases. Dermed sørges der for at de fleste faldgrupper bliver afdækket under en test. Yderligere bliver der også typisk kørt en automatiseret scanning af applikationen for at sikre at alle ”low-hanging-fruit” sårbarheder bliver fundet. Baseret på vores erfaring, så er det sjældent at vi finder kritiske sårbarheder gennem automatisering. Eksempelvis har vi fundet cross-sites-scripting (XSS) i vores manuelle del af testen, som de automatiserede scanninger ikke har kunnet identificere. Dette skyldes blandt andet at vi typisk skal omgå nogle filtre der har forsøgt at fjerne muligheden for XSS, men ikke er dækkene.

Hvilken skal jeg vælge?

I den ideelle verden ser vi at sikkerhed bliver tænkt ind fra starten af designfasen, at der bliver kørt SAST scanning af koden løbende i forbindelse med udviklingen, at applikationerne bliver regelmæssigt scannet af automatiserede DAST-scannere, og at der regelmæssigt bliver foretaget en manuel pentest af kritiske systemer for at finde eventuelle problemer det ikke har været muligt at finde automatisk.

For mange organisationer er dette ikke et realistisk kortsigtet billede. Generelt vil vi anbefale at starte med at få afdækket applikationen ved brug af automatiseret testing. Når eventuelle problemstillinger er blevet løst fra automatiseringen, så vil det give mening at få applikationen testet af en kvalificeret pentester. På denne måde får I afdækket de fleste ”low hanging fruit” sårbarheder, hvilket gør, at tiden brugt på manuelle tests kan have større fokus på at finde de problemstillinger og sårbarheder der ikke er nemme at spotte via automatiserede værktøjer.