Executive Summary
En pentest finder sjældent kun nye, eksotiske fejl. Den finder oftere kendte svagheder, som virksomheder allerede kunne have lukket med få ledelsesbeslutninger. For webportaler og login-flader går de samme fund igen i anerkendte teststandarder som OWASP Top 10, OWASP Web Security Testing Guide og NIST SP 800-115: for bred adgang, svag loginbeskyttelse, manglende hårdning, ujævn patching og for lidt logning.
For ledelsen er problemet enkelt. Hvis næste pentest igen finder adgangskontrolfejl, åbne administrative funktioner eller manglende overvågning, så er det ikke kun et teknisk problem. Det er et driftsproblem, et dokumentationsproblem og i mange tilfælde også et compliance-problem i forhold til GDPR artikel 32 og NIS2 artikel 21.
Løsningen behøver ikke være tung. Hvis du samler indsatsen i fem defensive greb og følger en fast 30-dages rytme med retest, kan din virksomhed både sænke sandsynligheden for kritiske fund og dokumentere, at forbedringerne virker i praksis. Målet er ikke en pæn rapport. Målet er færre alvorlige fund, mindre driftsrisiko og mere ro i maven.
Hvorfor de samme fund går igen
Mange ledelser tror, at en pentest primært afslører avancerede angreb. I praksis viser både OWASP Top 10 og OWASP WSTG, at klassiske fejl stadig dominerer. Broken access control ligger helt i toppen, og autentificering, sikker konfiguration og logging bliver ved med at dukke op i testforløb. NIST SP 800-115 peger samtidig på, at sikkerhedstest først skaber værdi, når fund bliver omsat til konkrete forbedringer og efterprøvet bagefter.
Det er præcis derfor, defensive valg betyder så meget. Hvis din virksomhed på forhånd beslutter, hvem der må hvad, hvordan login skal beskyttes, hvor hurtigt kritiske komponenter skal opdateres, hvilke hændelser der skal logges, og hvordan standardopsætning ser ud, så bliver næste pentest mindre dramatisk og langt mere brugbar.
Hvis du vil have et bredt overblik over testformen, kan du starte med vores side om pentest. Hvis fokus er hurtig kontrol af opsætning og baseline, er sikkerhedstjek ofte det rigtige første skridt.
1. Stram adgangsstyring før du køber flere værktøjer
Det mest almindelige fund i webportaler er ikke nødvendigvis et smart angreb. Det er, at en bruger kan se eller gøre mere end vedkommende burde. Det kan være kunde A, der kan tilgå kunde B’s data. Det kan være en medarbejderrolle, der kan eksportere mere end nødvendigt. Det kan være en gammel admin-konto, som stadig virker. Det er præcis den type fejl, OWASP fremhæver under broken access control.
For ledelsen er beslutningen enkel: adgang skal gives efter rolle og behov, ikke efter bekvemmelighed. Det betyder, at du bør kræve en fast gennemgang af roller, administratorer, servicekonti og eksterne leverandøradgange på tværs af portal, CMS, hosting og identitetsplatform.
Et godt ja eller nej-kriterium er dette: Kan en normal bruger kun se egne data, og kan ingen gamle eller ubrugte konti logge ind? Hvis svaret ikke er et klart ja, vil en pentest ofte finde det.
Hvis du arbejder i cloudmiljøer med mange brugere og rettigheder, er det også værd at se på, hvordan modenhedsanalyse kan bruges til at få styr på roller, ejerskab og dokumentation.
2. Gør login-fladen svær at misbruge
Login er stadig en af de hurtigste veje ind. OWASP peger på fejl i identifikation og autentificering som en tilbagevendende risikokategori. I praksis handler det ofte om manglende MFA, svage gendannelsesflows, for brede undtagelser eller gamle konti, der aldrig blev lukket.
For en SMV er det sjældent nødvendigt at starte med et stort identitetsprojekt. Det vigtigste er at tage få beslutninger konsekvent. Login til portal, adminflade, VPN, Microsoft 365 og andre forretningskritiske tjenester skal beskyttes ensartet. Du får langt mere effekt af en klar standard end af fem halve løsninger.
- Krav om MFA for alle administratorer og eksternt tilgængelige login
- Passkeys eller phishing-resistent MFA hvor det er muligt
- Ingen delte admin-brugere
- Lukkede eller deaktiverede konti ved fratrædelse samme dag
- Enkel og sikker nødadgang, som er dokumenteret og kontrolleret
Det er også her, mange virksomheder opdager, at identitetssikkerhed og websikkerhed hænger tæt sammen. Hvis login-fladen er svag, bliver resten af portalen det også. Har du Microsoft-miljøer, er et sikkerhedstjek ofte en hurtig måde at få overblik over MFA, konti og standardopsætning.
3. Gør patching til en ledelsesrutine, ikke en brandslukning
Når en pentest finder en kendt sårbar komponent eller en gammel adminflade med forældet software, skyldes det sjældent manglende viden. Det skyldes næsten altid manglende rytme. Derfor bør patching ikke behandles som ad hoc-arbejde, men som en fast driftsdisciplin.
Webportaler består ofte af flere lag. Der er selve applikationen, plugins, servere, framework, tredjepartsbiblioteker, load balancer, firewall og identitetsintegration. Hvis ét lag bliver glemt, bliver hele kæden sårbar. OWASP fremhæver både security misconfiguration og designsvagheder som klassiske årsager til, at kendte fejl overlever for længe.
Ledelsesgrebet er at indføre en enkel serviceaftale internt eller med leverandør: Hvor hurtigt patches internetvendte kritiske komponenter? Hvem godkender ændringer? Hvem kontrollerer efterfølgende, at opdateringen faktisk er slået igennem?
Et praktisk ja eller nej-kriterium kan være: Er alle internetvendte kritiske komponenter gennemgået og opdateret inden for 14 dage, eller findes der en godkendt risikovurdering for afvigelsen? Hvis ikke, vil det før eller siden vise sig i en test.
Vil du arbejde mere systematisk med den del, passer Forkant™ godt til virksomheder, der vil gøre sikkerhed til en fast driftstakt frem for enkeltstående projekter.
4. Log det, du faktisk skal reagere på
Mange virksomheder logger mere, end de bruger. Det giver ikke meget værdi. OWASP fremhæver logging and monitoring failures som et område, hvor organisationer mangler synlighed på sikkerhedshændelser, selv om data teknisk set findes.
For ledelsen handler det ikke om at samle flest logs. Det handler om at sikre, at de vigtigste hændelser kan ses, forstås og bruges. På en webportal og login-flade bør du som minimum kunne dokumentere mislykkede loginforsøg, ændringer i privilegier, oprettelse af nye administratorer, ændringer i MFA, usædvanlige dataudtræk og adgang til følsomme områder.
Hvis en pentester kan gennemføre flere mislykkede loginforsøg, ændre privilegier eller bevæge sig rundt i portalen uden at det bliver opdaget, så er problemet ikke kun teknisk. Det er også et ledelsesproblem, fordi virksomheden mangler et brugbart varslingsniveau.
Det menneskelige aspekt betyder også noget her. Der skal være en enkel regel for, hvem der reagerer på hvad. Hvis al overvågning ender i en delt postkasse, sker der sjældent noget. Hvis ansvar og eskalation er tydelig, stiger effekten markant.
Hvis du vil styrke den del i ledelses- og bestyrelsesperspektiv, kan workshop-formatet være nyttigt til at få roller, eskalation og beslutningsveje på plads.
5. Lås en sikker standardkonfiguration fast
Den måske mest undervurderede beslutning er at definere, hvad normal sikker opsætning egentlig er i din virksomhed. Uden en fast baseline glider systemer hurtigt. Nye miljøer bliver sat op lidt forskelligt. Midlertidige undtagelser bliver permanente. Test- og adminflader bliver stående åbne. Standardkonti bliver ikke fjernet. Fejlkonfiguration bliver dermed ikke en enkelt fejl, men en vane.
OWASP’s testguide bruges netop til at finde de huller, som opstår, når standardopsætning ikke er fastlagt eller håndhævet. Derfor bør du have en lille, konkret hardening-baseline for webportal og login-flade. Ikke en lang manual, men en kort standard som drift, leverandør og ledelse kan måle imod.
- Adminpanel er ikke åbent fra hele internettet uden ekstra beskyttelse
- Standardkonti, testkonti og demo-brugere er fjernet
- Fejlmeddelelser viser ikke unødige detaljer
- Kun nødvendige porte, services og plugins er aktive
- Sikkerhedsheaders, sessionindstillinger og timeout er gennemgået
Det er her, sikkerhedstjek ofte giver hurtig værdi, fordi fejlkonfigurationer typisk kan identificeres og lukkes hurtigere end større redesigns.
En 30-dages plan som ledelsen kan følge
Hvis du vil gøre forbedringen målbar, skal arbejdet køres i en enkel rytme. Ikke som et langt program, men som en kort indsats med tydelige ejere og ja eller nej-kriterier.
- Dag 1 til 5: Afgræns portal, login-flade, adminmiljø og ansvarlige ejere. Beslut de fem minimumskrav for adgang, login, patching, logging og konfiguration.
- Dag 6 til 10: Gennemfør hurtig lukning af åbenlyse fejl. Fjern gamle konti, stram roller, slå MFA til, luk unødige services og opdater kritiske komponenter.
- Dag 11 til 20: Dokumentér baseline. Gem skærmbilleder, systemudtræk, ændringslog og ejerskab. Det er denne del, der senere gør retest nyttig for både kunder, bestyrelse og audit.
- Dag 21 til 25: Kør målrettet kontrol eller pentest mod de områder, hvor risikoen er størst. Brug gerne pentest til dybde og sikkerhedstjek til bred verifikation.
- Dag 26 til 30: Kør retest på de lukkede fund og opdater en 1-sides status til ledelsen: hvad blev fundet, hvad blev lukket, hvad resterer, og hvornår testes der igen.
Den rytme er nyttig, fordi den flytter fokus fra rapportproduktion til forbedring. Retest er ikke bare et ekstra bilag. Det er beviset på, at din virksomhed faktisk har reduceret risikoen.
Sådan gør du retest til et ledelsesværktøj
Mange virksomheder bestiller en pentest, modtager rapporten og går videre til næste projekt. Så mister de den vigtigste effekt. En retest gør to ting. Den bekræfter, at fund er lukket, og den viser, om organisationen har en arbejdsform, der kan gentages. Det er præcis den type dokumentation, der er nyttig i dialog med kunder, bestyrelse og ved arbejde med compliance og modenhed.
Du behøver ikke gøre det kompliceret. Bed om en retest med et klart før og efter-billede. For hvert væsentligt fund bør du kunne svare ja eller nej på tre spørgsmål: Er fejlen lukket? Kan det dokumenteres? Er kontrollen nu en fast del af driften?
Hvis svaret er ja til alle tre, har du ikke bare forbedret sikkerheden. Du har også gjort næste pentest mindre risikabel og mere værdifuld.
Næste skridt for din virksomhed er derfor enkelt: vælg din webportal og login-flade som første defensive fokusområde, beslut fem minimumskrav i ledelsen og planlæg en retest inden for 30 dage. Så bliver sikkerhed et styringsværktøj i stedet for endnu en rapport i skuffen.