En IT-afdeling kan godt vide, hvor skoen trykker: en server, der mangler opdateringer, en gammel protokol, der stadig er slået til, eller en konto med flere rettigheder end nødvendigt. Spørgsmålet er, om testeren skal have den viden før start. Svaret er som udgangspunkt ja, med forbehold. At dele listen sparer testtid og gør det muligt at afprøve, om jeres eget overblik holder. Prisen er, at listen skal være rigtig, at den behandles fortroligt, og at det står klart i aftalen, hvad testeren skal gøre med den.
Hvad det giver at dele listen
Den britiske myndighed NCSC anbefaler i sin vejledning om penetrationstest, at kunden deler en aktuel sårbarhedsvurdering med testerne, hvis den findes, og at testen så kan vise, hvor præcis og dækkende vurderingen er. Det er den vigtigste gevinst. Testen bliver en kontrol af jeres eget arbejde, ikke kun en liste over fund.
- Testtid bruges på det ukendte · testeren skal ikke bruge dage på at finde det, I allerede ved.
- Jeres overblik bliver afprøvet · fund, der ikke stod på listen, viser, hvor jeres egen kontrol har huller.
- Sammenhænge kan undersøges · testeren kan se, om kendte svagheder kan kombineres til noget alvorligere, end I troede.
- Bedre prioritering bagefter · rapporten kan skelne mellem det, I vidste, og det, der er nyt.
NCSC skriver også, at I i en ideel verden bør vide, hvad testerne vil finde, før de finder det, og at de fund, I ikke kendte, bør have særlig opmærksomhed, så lignende problemer kan opdages fremover. Det er netop den sammenligning, en delt liste gør mulig.
Hvad det koster
At dele listen er ikke uden ulemper, og de skal være kendt, før beslutningen træffes.
- Fortrolighed · listen beskriver jeres svagheder samlet ét sted og skal behandles som det. Den sendes ad en sikker kanal og kun til dem, der skal bruge den.
- Falsk tryghed · en svaghed, der står på listen, kan blive behandlet som afklaret, selv om den er værre end beskrevet.
- Styring af testen · listen kan trække testeren mod det kendte og væk fra det ukendte, hvis aftalen ikke er tydelig.
- Arbejde før testen · listen skal være opdateret. En gammel liste med lukkede punkter og manglende nye skaber mere forvirring end hjælp.
Ulemperne kan styres. De behøver ikke være en grund til at lade være, men de er en grund til at gøre det ordentligt.
Tre måder at gøre det på
Der er flere måder at håndtere kendte svagheder på, og valget hænger sammen med testens formål.
- Del listen og bed om bekræftelse · testeren får listen og kontrollerer stikprøvevis, om punkterne er rigtige og vurderet korrekt, men bruger mest tid på det ukendte.
- Del listen og bed testeren springe den over · testeren noterer, at punkterne er kendte, og bruger tiden andre steder. Hurtigt, men listens rigtighed bliver ikke afprøvet.
- Del ikke listen, sammenlign bagefter · testeren arbejder uden kendskab, og I sammenligner rapporten med jeres egen liste. Det viser, hvor godt jeres overblik dækker, men koster testtid.
Hvor meget testeren generelt skal vide om miljøet, er et spørgsmål om testtypen og hører til bestillingen. Køberens forklaring af valget står på penetrationtest.dk. Her er spørgsmålet alene, hvad IT gør med sin egen liste.
Hvad listen skal indeholde
Hvis listen deles, skal den være kort og præcis. Den skal ikke være en eksport af alt fra jeres scanningsværktøj.
- Svagheden · beskrevet i en sætning, så testeren kan genkende den.
- Hvor · hvilket system eller område det drejer sig om.
- Jeres vurdering · hvor alvorlig I mener, den er, og hvorfor.
- Status · om den er under rettelse, midlertidigt afhjulpet eller accepteret. → Midlertidige afhjælpninger
- Kilde · om den stammer fra egen scanning, en tidligere test eller en leverandørs advarsel. → Sårbarhedsscanning mellem testene
Gennemgå listen kort før testen, så lukkede punkter er fjernet, og nye er kommet med. Drives dele af miljøet af en driftsleverandør, så bed leverandøren om at bidrage med de svagheder, den kender i sin del. Ellers dækker listen kun det, I selv har overblik over, og sammenligningen bagefter bliver skæv. → Netværkstegning og systemoversigt
Ret ikke alt i sidste øjeblik
En fristelse er at rette de kendte svagheder lige før testen, så rapporten ser pænere ud. NIST beskriver i sin vejledning om sikkerhedstest, at ændringer, der laves op til en test for at gøre systemerne mere modstandsdygtige, som regel kun holdes i testperioden, hvorefter systemerne vender tilbage til den tidligere opsætning. Så viser testen et miljø, der ikke findes resten af året.
Det betyder ikke, at I skal lade være med at rette. Rettelser, der er planlagt og holder, er altid gode. Men en rettelse, der er lavet for testens skyld og fjernes igen bagefter, giver et misvisende billede og spilder testen. Hvis noget er rettet kort før, så skriv det på listen, så testeren kan kontrollere, om rettelsen virker. → Når et system ikke kan opdateres
Når rapporten kommer
Bed om, at rapporten markerer, hvilke fund der stod på jeres liste, og hvilke der er nye. Det gør det lettere at vurdere jeres eget overblik og at prioritere. Et fund, der var kendt, men vurderet for mildt, er et lige så vigtigt resultat som et nyt fund. → Fra fund til opgave
Brug forskellen til at forbedre jeres egen kontrol. Hvorfor blev de nye fund ikke fanget af scanning, gennemgange eller leverandørernes advarsler? Svaret peger på, hvor processen skal styrkes.
Det skal I lade være med
- At sende en ufiltreret eksport fra scanningen. Den skal kunne læses og bruges.
- At sende listen ad en usikker kanal. Den samler jeres svagheder ét sted.
- At rette punkter midlertidigt for testens skyld. Det giver et falsk billede.
- At undlade at sige, hvad testeren skal gøre med listen. Bekræfte, springe over eller sammenligne.
- At behandle et kendt fund som mindre vigtigt. Det skal stadig rettes.
Hvad kan og ikke kan konkluderes
En test med delt liste kan vise, om jeres kendte svagheder er rigtigt vurderet, og hvad I ikke vidste. Den kan ikke vise, hvad testeren ville have fundet uden listen, og den afprøver ikke punkter, testeren blev bedt om at springe over. Står et punkt ikke i rapporten, betyder det ikke nødvendigvis, at det er i orden, kun at det ikke blev undersøgt igen.
Tjekliste før listen sendes
- ☐ Er listen opdateret og kort?
- ☐ Har hvert punkt system, vurdering og status?
- ☐ Er det aftalt, om testeren skal bekræfte, springe over eller sammenligne?
- ☐ Sendes listen ad en sikker kanal til få modtagere?
- ☐ Er rettelser lavet kort før testen markeret?
- ☐ Er det aftalt, at rapporten skelner mellem kendte og nye fund?
Kilder
- NCSC: Penetration testing: en aktuel sårbarhedsvurdering bør deles med testerne; testen kan vise, hvor præcis og dækkende den er; fund, I ikke kendte, bør have særlig opmærksomhed.
- NIST SP 800-115: ændringer lavet op til en test holdes som regel kun i testperioden, hvorefter systemerne vender tilbage til den tidligere opsætning.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Sårbarhedsscanning mellem testene · Fra fund til opgave
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
