Penetration-test

Samme fund hos mange kunder: når standardopsætningen er årsagen

Samme fund hos mange kunder: når standardopsætningen er årsagen

En kundes rapport nævner en konto med for brede rettigheder, en gammel indstilling i klienternes opsætning eller en regel i firewallen, som er åben mod mere end nødvendigt. Teknikeren genkender den med det samme, for det er jeres egen standard, og den blev indført af gode grunde engang. Så er fundet ikke kun kundens. Det findes hos alle kunder, der er sat op efter samme skabelon. Opgaven er at rette årsagen i skabelonen, kontrollere hvilke kunder der er berørt, og rulle rettelsen ud i en rækkefølge, der tager hensyn til både risiko og drift.

Det kræver, at I ser kundens rapport som information om jeres egen leverance, og ikke kun som en opgave hos én kunde.

Sådan genkender I et fælles fund

Et fund peger på jeres standard, når årsagen ligger i noget, I har bygget én gang og genbrugt. Spørg om fundet stammer fra:

  • Skabeloner · den måde nye servere, klienter eller lejere sættes op på.
  • Scripts og politikker · det, jeres fjernstyring eller jeres standardopsætning rulles ud med.
  • Fælles konti · servicekonti eller administratorkonti, der oprettes ens hos alle.
  • Faste valg · beslutninger, I har truffet for alle kunder, fx en indstilling, der blev slået fra for at undgå supporthenvendelser.
  • Onboarding · den tjekliste, nye kunder går igennem, hvor et punkt mangler.

Hvis svaret er ja, er fundet en del af jeres leverance. NCSC (UK) anbefaler, at svagheder, organisationen ikke kendte, får særlig opmærksomhed, så lignende forhold kan findes fremover. Hos en MSP betyder det, at fundet også skal søges hos de andre kunder. → Gør rettelserne permanente

Kundens rapport er fortrolig

Rapporten tilhører kunden, der bestilte testen. I må bruge den viden, I får gennem den, til at rette jeres egen standard, men I må ikke videregive kundens fund til andre kunder. Når I informerer andre kunder, skal det ske som jeres egen oplysning om jeres leverance, uden henvisning til hvem der blev testet.

Formuler det som det, det er: I har fundet en svaghed i jeres standardopsætning, den kan findes hos jer som kunde, og I retter den. Det er sandt, og det afslører ikke den første kundes forhold. Overvej at aftale med kunderne på forhånd, at viden fra deres test må bruges til at forbedre jeres standard, uden at kunden nævnes. → Fund hos kunden

Find omfanget

Næste skridt er at finde ud af, hvor fundet findes. Det kan I gøre med jeres egne midler: jeres oversigt over kunder og skabeloner, den opsætning, fjernstyringen kan vise, og jeres egen kontrol. Det kræver ikke en ny penetrationstest hos hver kunde. Men det kræver, at nogen får tid til at gå listen igennem kunde for kunde og noterer, hvad der blev fundet hvor. → Sårbarhedsscanning mellem testene

Del kunderne i grupper:

  1. Fundet findes, og opsætningen er standard · rettelsen kan rulles ud efter samme plan.
  2. Fundet findes, men opsætningen afviger · rettelsen skal tilpasses kunden.
  3. Fundet findes ikke · enten fordi kunden er sat op efter en nyere skabelon, eller fordi kunden har fået en anden løsning.
  4. Uafklaret · kunder, hvor I ikke kan se opsætningen uden at undersøge nærmere.

Den sidste gruppe er i sig selv et resultat. Den viser, hvor jeres overblik over kunderne er mangelfuldt, og hvor næste fælles fund kan gemme sig uden at blive opdaget.

Ret i skabelonen først

Ret årsagen i skabelonen eller scriptet, før I begynder at rette hos kunderne. Ellers bliver nye kunder sat op med samme fejl, mens I retter de gamle. Afprøv rettelsen hos jer selv eller hos en testkunde, og beskriv, hvad den kan påvirke. Nogle rettelser mærkes af brugerne, andre kan stoppe et ældre system. → Rettelser uden at stoppe driften

Rul derefter ud i en rækkefølge, hvor de kunder, fundet betyder mest for, kommer først. Det kan være kunder, hvor den berørte del er tilgængelig fra internettet, eller hvor følsomme data er i spil. Kunder med afvigende opsætning kommer på en særskilt liste med en ansvarlig tekniker, som kender kunden og kan vurdere, hvordan rettelsen skal tilpasses.

Hvem betaler

Hvem der betaler for at rette en svaghed i jeres standard, bør stå i driftsaftalen. Aftal på forhånd, om rettelser af fejl i jeres egen leverance er dækket af aftalen eller faktureres for sig, så spørgsmålet ikke skal afgøres, mens fundet ligger på bordet. Rettelser, der hæver niveauet ud over det, kunderne har købt, er en anden sag og kan tilbydes som nye opgaver. Skeln tydeligt mellem de to, så kunderne kan se, hvad der er rettelse af jeres standard, og hvad der er et tilbud. → Rettelser efter kundens test

Gør standarden til et emne for sig

Et fælles fund viser, at jeres standard er et af de vigtigste sikkerhedsforhold i hele kundekredsen. Den fortjener derfor sin egen ejer, sin egen ændringslog og sin egen gennemgang. Når skabelonen ændres, skal det kunne ses, hvorfor og hvornår, og hvilke kunder der har fået ændringen.

Overvej også at lade standarden indgå, når jeres egen platform testes. En testkunde, der er sat op præcis efter skabelonen, giver et billede, der gælder for alle kunder med samme opsætning. Det er en mere effektiv vej til at finde fælles fund end at vente på, at de dukker op i kundernes rapporter én ad gangen. → Test af MSP’ens egen sikkerhed

Det skal I lade være med

  • At rette hos én kunde og glemme resten · fundet findes hos alle med samme skabelon.
  • At videregive kundens rapport · brug viden, ikke dokumentet.
  • At rette hos kunderne før skabelonen · nye kunder får fejlen med.
  • At rulle ud uden afprøvning · én fejl i rettelsen rammer alle.
  • At lade det være uafklaret, hvem der betaler for rettelser af egen standard · det skal aftales, før fundet er der.
  • At lade uafklarede kunder ligge · de skal undersøges.

Hvad kan og ikke kan konkluderes

Et fund i én kundes test viser, at svagheden fandtes hos den kunde. At den findes hos andre kunder, er en konklusion, I selv skal efterprøve ud fra jeres egne oplysninger. Testen hos den første kunde siger ikke noget om andre forhold hos de øvrige kunder. Og en rettet skabelon er først en rettet leverance, når rettelsen er kontrolleret hos de kunder, den skulle nå.

Tjekliste til et fælles fund

  • ☐ Er årsagen sporet til en skabelon, et script eller en fast praksis?
  • ☐ Er skabelonen rettet og afprøvet?
  • ☐ Er kunderne delt i grupper efter, om fundet findes?
  • ☐ Er uafklarede kunder undersøgt?
  • ☐ Er rækkefølgen for udrulning lagt efter risiko?
  • ☐ Er kunderne informeret uden henvisning til den første kunde?
  • ☐ Er rettelsen kontrolleret hos alle berørte?

Kilder

  • NCSC (UK): Penetration testing: anbefaling om at give svagheder, organisationen ikke kendte i forvejen, særlig opmærksomhed, så lignende forhold kan findes fremover, og om at bruge testen til at forbedre egne processer.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: Fjernstyringsværktøjer som testområde · Læring i driften efter testen

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres miljø testes?

Fortæl kort, hvilke dele af jeres miljø der skal testes, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.