En sikkerhedsadvarsel fra leverandøren af firewallen, fjernadgangen eller lagersystemet sætter IT-afdelingen under tidspres, og spørgsmålet om en penetrationstest dukker hurtigt op. Rækkefølgen er dog enkel: først kortlægning og opdatering efter leverandørens anvisning, derefter en vurdering af, om der er tegn på misbrug, og først til sidst en eventuel test. En test er sjældent det rette første svar på en kendt sårbarhed, fordi det, der skal ske, allerede er beskrevet af leverandøren.
Testen får sin plads bagefter, når der er et spørgsmål, som en opdatering ikke kan besvare.
Har vi det, og hvor står det?
Det første arbejde er at finde ud af, om advarslen overhovedet gælder jer. Advarsler angiver typisk produkt, udgaver og nogle gange bestemte funktioner, som skal være slået til, før svagheden er relevant. Sammenhold det med jeres egen oversigt.
- Produkt og udgave · hvilke enheder kører en berørt version?
- Funktion · er den del af produktet, advarslen handler om, i brug hos jer?
- Placering · kan enheden nås fra internettet, eller står den kun på det interne net?
- Drift · administrerer I enheden selv, eller gør driftsleverandøren eller hostingfirmaet det?
Det sidste punkt glemmes let. Hvis en MSP drifter udstyret, er det MSP’en, der skal opdatere, men det er stadig jer, der skal vide, at det er sket. Bed om en skriftlig bekræftelse med dato.
Hvis oversigten ikke kan svare på spørgsmålene, er det et fund i sig selv. Advarslen har så vist, at I ikke ved, hvilke udgaver der kører hvor. Gør arbejdet færdigt nu, mens opmærksomheden er der, og læg resultatet ind i den oversigt, I vedligeholder. Næste advarsel kommer, og den bliver lettere at håndtere, hvis kortlægningen allerede findes. → Overblik over jeres internetvendte systemer
Opdatering kommer før test
Når en rettelse findes, er den hurtigste vej at installere den. Leverandørens advarsel er den primære kilde til, hvad der skal gøres, og den kan også nævne midlertidige foranstaltninger, hvis rettelsen ikke er klar endnu.
To offentlige kilder kan hjælpe med at vurdere hastværket. Sårbarheden kan have et nummer i CVE-kataloget, som gør det lettere at tale præcist om den med leverandører og kolleger. Det amerikanske cybersikkerhedsagentur CISA fører desuden et katalog over sårbarheder, der er kendt udnyttet. Står jeres sårbarhed der, er der tale om noget, der bliver brugt i angreb, og ikke kun en teoretisk mulighed.
Alvorlighedsgraden fra CVSS beskriver selve svagheden. Den tager ikke stilling til, om netop jeres enhed vender mod internettet. En kritisk sårbarhed i en enhed, der kan nås af alle, skal behandles anderledes end samme sårbarhed bag flere lag af afskærmning.
Hold samtidig en kort log over, hvad der er gjort: hvornår advarslen kom, hvornår enhederne blev opdateret, og hvem der bekræftede det. Loggen er nyttig, hvis ledelsen eller en kunde spørger, og den er uundværlig, hvis det senere viser sig, at svagheden var udnyttet, før rettelsen kom på.
Når rettelsen ikke kan installeres med det samme
Nogle gange kan rettelsen ikke komme på med det samme. Den findes måske ikke endnu, enheden kræver et servicevindue, eller en ældre model får slet ikke rettelsen. Så handler arbejdet om at begrænse, hvad svagheden kan bruges til.
På begrebsniveau kan det være at afskære adgangen udefra, at slå den berørte funktion fra, at begrænse, hvem der kan nå enheden, eller at øge overvågningen af den. Skriv beslutningen ned med en ejer og en dato for, hvornår den skal ses igen. → Midlertidige afhjælpninger
Er enheden så gammel, at leverandøren ikke længere udsender rettelser, er advarslen et signal om, at udskiftningen ikke kan vente meget længere. → Et system, der ikke kan opdateres
Tegn på, at svagheden allerede er brugt
Leverandører og myndigheder kan skrive i advarslen, at kunder bør undersøge, om svagheden er blevet udnyttet, før rettelsen kom på. Det er ikke en penetrationstest. Det er en undersøgelse af, om der er sket en hændelse, og den kræver andre kompetencer og en anden tilgang.
Hvis I ser tegn på misbrug, skal sagen behandles efter jeres beredskabsplan, og en test venter, til hændelsen er håndteret. En test midt i en hændelse kan forstyrre sporene og gøre det sværere at forstå, hvad der skete.
Hvornår en ekstern test bagefter giver mening
Når opdateringen er på, og der ikke er tegn på misbrug, kan en ekstern test have et formål. Det gælder især i disse situationer:
- Advarslen afslørede, at enheden var mere synlig udefra, end I troede, og I vil vide, om andet også er det.
- Der er mange enheder af samme type, og I er ikke sikre på, at alle er opdateret og ens sat op.
- Opdateringen ændrede opsætningen, og I vil vide, om den nye opsætning holder.
- Ledelsen eller en kunde spørger, om grænsen mod internettet er i orden, og et uafhængigt svar har værdi.
I alle fire tilfælde handler testen om mere end den ene sårbarhed. Det er netop det, der gør den relevant. → Typiske fund i en ekstern test
Hvis spørgsmålet kun er, om én bestemt rettelse er installeret, er en test et dyrt svar. Versionsoplysninger fra enheden og en løbende scanning af jeres egne adresser kan svare hurtigere. → Sårbarhedsscanning mellem testene
Det skal I lade være med
- At vente på en test, før I opdaterer. Rettelsen er det vigtigste skridt.
- At gå ud fra, at driftsleverandøren har styr på det. Bed om bekræftelse med dato og version.
- At bruge CVSS-scoren som eneste prioritering. Placering og eksponering afgør meget.
- At blande test og hændelsesundersøgelse. Er der tegn på misbrug, er det en hændelse.
- At lade midlertidige foranstaltninger blive permanente uden beslutning. Giv dem en ejer og en dato.
Hvad kan og ikke kan konkluderes
En opdatering lukker den beskrevne svaghed, hvis den er installeret korrekt. Den siger intet om, hvorvidt enheden var udnyttet før, eller om andre forhold ved enheden er i orden. En efterfølgende ekstern test kan vise, hvordan grænsen mod internettet ser ud på testtidspunktet. Den kan ikke bevise, at der ikke er sket noget tidligere, og den beskytter ikke mod den næste advarsel. Det gør en fast rutine for at følge med i leverandørernes meddelelser. → Opdateringsstatus på klienter og servere
Tjekliste, når advarslen lander
- ☐ Er det afklaret, om produktet, udgaven og funktionen findes hos jer?
- ☐ Er det kendt, om enheden kan nås fra internettet?
- ☐ Er rettelsen installeret, eller er der en dokumenteret midlertidig foranstaltning?
- ☐ Har driftsleverandøren bekræftet skriftligt?
- ☐ Er det vurderet, om der er tegn på misbrug, før rettelsen kom på?
- ☐ Er det besluttet, om en test bagefter har et selvstændigt spørgsmål?
Kilder
- CVE: det fælles katalog over offentligt kendte sårbarheder.
- CISA, Known Exploited Vulnerabilities Catalog: oversigt over sårbarheder, der er kendt udnyttet, som input til prioritering.
- FIRST CVSS v4.0: alvorlighedsgrad for sårbarheder.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Et system, der ikke kan opdateres · Opdateringsstatus på klienter og servere
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
