Black box, grey box og white box: hvor meget skal testeren vide?

Før en penetrationstest skal I bestemme, hvor meget testeren må vide om systemerne på forhånd. Valget afgør, hvilke spørgsmål testen kan svare på, for viden er det, der skiller en angriber udefra fra en medarbejder eller en leverandør med adgang.

Begreberne black box, grey box og white box bruges om netop det valg. De er ikke tre kvalitetsniveauer. De er tre forskellige udgangspunkter, der giver tre forskellige slags svar.

Tre niveauer af viden

Forskellen ligger i, hvad testeren får udleveret, før arbejdet begynder:

Black box · testeren får et mål, for eksempel et domæne eller en IP-adresserække, og intet andet.
Grey box · testeren får det, en almindelig bruger har: en konto, en rolle og en kort beskrivelse af systemet.
White box · testeren får adgang til arkitektur, konfiguration og eventuelt kildekode.

Mellem de tre findes mange varianter. En grey box-test af en webapplikation kan have to konti med forskellige roller. En black box-test af netværket kan få at vide, hvilke adresser der er uden for scope. Det vigtige er, at aftalen beskriver præcist, hvad der udleveres. → Scope i en penetrationstest

Ved en kundeportal kan I bruge en enkel oversigt over oplysningerne: hvilke konti udleveres, hvilke beskrivelser følger med, og hvilke dele skal vurderes uden den viden? Oversigten gør betegnelsen forståelig for den indkøber, der ikke kender løsningen i detaljer.

Black box: testeren starter udefra

Ved black box får testeren kun begrænset viden om målet. For en webshop kan opgaven være at vurdere den adgang, en fremmed har uden en udleveret kundekonto. Modellen skal beskrives i bestillingen, så der ikke opstår tvivl om forudsætningerne.

Fordelen er perspektivet uden virksomhedens interne forklaringer. Rapporten kan vise, hvad der blev påvist med de oplysninger, testeren havde. For webshoppen kan det være relevant ved en beslutning om den offentlige del af løsningen. Det er ikke samtidig et svar om alle funktioner bag kundernes login.

Den afsatte tid sætter en grænse for undersøgelsen. Hvis opgaven også kræver, at testeren selv skaffer overblik over kundeportalens opbygning, er der mindre tid tilbage til de enkelte funktioner. Vælg derfor black box, fordi det begrænsede kendskab er vigtigt for spørgsmålet, ikke fordi betegnelsen lyder mest grundig.

Grey box: en almindelig brugers udgangspunkt

Ved grey box får testeren udvalgt viden eller adgang, som passer til en bestemt situation. I en kundeportal kan det være konti til forskellige kundetyper og en beskrivelse af deres roller. Målet kan være at vurdere, om oplysninger og funktioner er adskilt som tilsigtet.

Kontiene gør det muligt at undersøge de omfattede funktioner efter login. Bestillingen bør fortælle, hvad hver kunde må se og gøre. Ellers mangler både testeren og rapportens læser grundlaget for at skelne mellem en tilladt funktion og en fejl i adgangen.

I et ERP-system kan lager, salg og økonomi have forskellige roller. Vælg de relevante roller ud fra arbejdsopgaverne. En test med salgsadgang dækker ikke automatisk økonomiafdelingens muligheder. Bed om, at rapporten viser, hvilke roller der faktisk indgik, frem for blot at kalde hele opgaven grey box.

White box: adgang til dokumentation og kode

Ved white box får testeren et bredere indblik i den løsning, der skal undersøges. Det kan være systembeskrivelser, rettighedsoversigter og relevant kildekode. For et nyt ERP-system kan dokumentationen forklare, hvordan afdelingerne er tænkt adskilt, og hvilke oplysninger der kræver særlig beskyttelse.

Modellen er relevant, når spørgsmålet kræver kendskab til opbygningen. En kundeportal kan eksempelvis have funktioner, som er vanskelige at forstå uden en beskrivelse fra softwareleverandøren. Den viden skal hjælpe undersøgelsen, mens omfang og begrænsninger stadig står tydeligt i aftalen.

White box gør ikke automatisk hele koden eller alle indstillinger til en del af opgaven. Hvis virksomheden udleverer dokumentation om både webshop og ERP-system, skal det fortsat fremgå, hvilke dele der undersøges. Afklar også, hvad der gennemgås, og hvad der afprøves. → Sårbarhedsscanning, sikkerhedstjek eller penetrationstest?

Tid og dybde

Forhåndsviden påvirker, hvad tiden bruges på. I en kundeportal kan en beskrivelse af brugerrollerne hjælpe med at rette undersøgelsen mod de funktioner, virksomheden skal have vurderet. Uden beskrivelsen kan en del af arbejdet i stedet gå med at afklare løsningens opbygning.

Sammenlign derfor ikke tilbud alene på black box, grey box og white box. Se efter, hvilke funktioner og roller hvert tilbud omfatter. En afgrænset undersøgelse af kundernes ordrehistorik er noget andet end en opgave, der også omfatter medarbejdernes administration af webshoppen.

Spørg, hvilke dele der må fravælges, hvis den planlagte dækning ikke kan nås. For et ERP-system kan det være vigtigt at prioritere økonomirollen før mindre brugte funktioner. Prioriteringen bør kunne genfindes i rapportens beskrivelse af det gennemførte arbejde. Den er ikke en garanti for, at alle væsentlige fejl bliver fundet.

Hvilken model passer til hvilken test?

Valget følger spørgsmålet:

Hvad kan en fremmed se og bruge fra internettet? Black box mod jeres eksterne flade. → Ekstern eller intern penetrationstest
Kan en kunde eller bruger komme til mere, end rollen tillader? Grey box med en eller flere testkonti.
Er et nyt system bygget sikkert, før det går i drift? White box med dokumentation og eventuelt kode.
Hvor langt kan en angriber komme, når adgangen først er der? Intern test, typisk som grey box fra en almindelig arbejdsstation.

Skal testen dokumentere noget over for en kunde, er det en god idé at spørge kunden, hvilken model de forventer. En kunde kan eksempelvis efterspørge dokumentation for adskillelsen mellem brugere i en kundeportal. Softwarehuse, der står i den situation, finder mere på pentestrapport.dk.

Lad systemejeren og rapportens modtager læse samme bestilling. Ved et nyt ERP-system kan systemejeren ønske vurdering af økonomiroller, mens ledelsen forventer svar om hele løsningen. Den forskel skal være afklaret, før betegnelsen for modellen bliver valgt.

Kombinationer

Modellerne kan kombineres, hvis formålet kræver flere perspektiver. En kundeportal kan først vurderes uden udleveret adgang og derefter med aftalte kundekonti. Hver del bør have et klart spørgsmål og en beskrivelse af den viden, der var til rådighed.

Rapporten skal holde resultaterne fra delene adskilt. Hvis et fund i webshoppen forudsatte en udleveret kundekonto, må det ikke fremstilles som et fund uden login. Den opdeling er vigtig, når ledelsen eller en kunde kun læser resuméet og skal forstå konsekvensen.

Teknik, medarbejdere og fysisk adgang kan også indgå i en bredere, særskilt aftalt undersøgelse. For en virksomhed med kundeservice kan spørgsmålet eksempelvis være samspillet mellem systemadgang og medarbejdernes reaktion. Se → Hackere og deres hatte og red-teaming.dk.

Det skal I lade være med

At vælge black box for at “gøre det realistisk” med for lidt tid. Testen bliver realistisk i formen, men ikke i resultatet.
At holde viden tilbage, I gerne vil have testet. Kender I et svagt punkt, så sig det. Testen skal finde det, I ikke kender.
At give white box-adgang uden at beskrive den. Står det ikke i rapporten, hvad testeren fik udleveret, kan ingen bagefter vurdere fundene.
At sammenligne to tests med forskellig model som om de var ens. Færre fund i en black box-test betyder ikke bedre sikkerhed end i en white box-test.
At glemme testkonti og testdata. Grey box kræver konti med de rigtige roller og data, der må ændres.

Ved en webshop bør forventningen også være tydelig for softwareleverandøren. Hvis leverandøren forventer en gennemgang af alle funktioner, mens aftalen kun dækker den offentlige del, vil parterne læse samme resultat forskelligt. Brug bestillingen til at gøre forskellen synlig.

Hvad kan og ikke kan konkluderes

En black box-test kan vise, hvad der var synligt og sårbart udefra i testperioden med den tid, der var til rådighed. Den kan ikke vise, at der ikke findes huller bag login.

En grey box-test kan vise, hvad en bruger med de udleverede roller kunne nå. Den siger ikke meget om roller, der ikke blev testet.

En white box-test kan vise fejl i opbygningen af det, der blev gennemgået. Den siger ikke noget om systemer uden for scope, og den efterligner ikke en bestemt angriber.

Ingen af de tre kan bevise, at et system er sikkert. De kan vise, hvad der blev fundet med den viden, tid og metode, der blev aftalt. Derfor skal modellen stå i rapporten. → Sådan læser I en pentestrapport

For et ERP-system bør konklusionen knyttes til de undersøgte roller og funktioner. Et fund med lageradgang kan være vigtigt, men siger ikke alene, hvad en økonomimedarbejder kan gøre. Oplysninger om dækningen gør resultatet anvendeligt uden at give det en større rækkevidde, end undersøgelsen har.

Tjekliste før I vælger

☐ Har vi skrevet det spørgsmål ned, testen skal besvare?
☐ Har vi besluttet, hvad testeren får udleveret: mål, konti, dokumentation, kode?
☐ Er der testkonti med de roller, vi vil have afprøvet?
☐ Har vi spurgt den kunde eller det tilsyn, testen skal dokumentere noget over for, hvilken model de forventer?
☐ Er tiden afpasset efter modellen?
☐ Står modellen i aftalen, så den kan gengives i rapporten?

Forberedelsen står i → Før penetrationstesten, og valget af tester i → Uafhængig penetrationstest.

Gennemgå svarene med systemejeren. Ved kundeportalen skal den valgte model passe til de kundetyper og oplysninger, der skal vurderes. Hvis svarene peger i forskellige retninger, så præcisér spørgsmålet, før opgaven bestilles.