IT sikkerhed SMB: 7 fejl der giver gentagne brud

I bliver ramt af phishing eller ransomware, får systemerne op igen – og så sker det igen. Det er næsten altid fordi I genskaber samme svagheder: identitet, rettigheder, backup og manglende læring fra hændelsen. IBM peger på kompromitterede credentials som en af de mest typiske startvektorer (2024). Målet her er enkelt: færre gentagne brud ved at lukke rodårsagerne.

• Stop konto- og token-tyveri: håndhæv Conditional Access + phishing-resistant MFA på admin og højrisiko-brugere.
• Fjern “zombie-adgang”: automatisér offboarding og kør månedlig review af gæster, servicekonti og privilegier.
• Gør backup brugbar i praksis: indfør immutable/air-gapped kopier og test restore med RTO/RPO, ikke kun “backup job succeeded”.
• Skær ned på angrebsfladen i M365: slå legacy auth fra, stram app-consent, og log alt, der betyder noget.
• Gør Incident Response gentagelses-sikker: dokumentér root-cause, ryd persistence, og mål “tid til lukning” – ikke kun “tid til drift”.

Hvorfor gentagne brud rammer SMB hårdere end første gang

Efter første brud er I ofte presset på tid: drift skal op, kunder skal informeres, og der skal findes en “hurtig løsning”. Problemet er, at hurtige løsninger tit kun fjerner symptomet. Verizon DBIR viser, at den menneskelige faktor er involveret i en stor del af brud (2024), og Microsoft beskriver samtidig en stigning i password-baserede angreb og metoder som MFA-fatigue og token-tyveri (Microsoft Digital Defense Report 2024). Det giver en gentagelses-effekt: samme adgangsvej virker igen, hvis I ikke ændrer måden I styrer identitet, rettigheder og enheder på.

Definition vi bruger i denne artikel: Et “gentaget brud” er, når I bliver kompromitteret igen, fordi rodårsagen fra første hændelse ikke blev fjernet (fx samme konto-/tokenproblem, samme backup-svaghed, samme manglende patching eller samme governance-hul).

Fejl der koster jer gentagne brud: De 7 “synder”

1) I lapper hullet – men laver ingen root-cause og “persistence”-rydning

Hvis angriberen har oprettet en ekstra OAuth-app, en mail-forwarding-regel eller en ny admin-konto, kan de komme tilbage, selv om I har ændret passwordet. Det er klassisk i Microsoft 365 kompromitteringer.

Gør i stedet: auditér Entra ID sign-ins, revisionslog, mailbox rules, app registrations og admin-roller. Fjern alt, der ikke kan forklares.

Før → Efter #1
Før: I nulstiller passwords og “håber”, det stopper.
Efter: I kører en fast udrydningspakke (tokens, app-consent, regler, privilegier) og dokumenterer fund. Resultat: færre tilbagefald, fordi bagdøre fjernes – ikke kun adgangskoden.

2) I tror standard MFA er nok (MFA-fatigue, AiTM og token-tyveri)

Angribere går efter session-tokens og prøver at presse brugere til at godkende en login-anmodning (MFA-fatigue). Microsoft peger på disse metoder som udbredte (2024).

Gør i stedet (beslutningsregel): Hvis en konto kan godkende betalinger, kundedata, admin-opgaver eller adgang til SharePoint/Teams med følsomme filer, så skal den have phishing-resistant MFA (fx FIDO2/Windows Hello) + Conditional Access med device compliance.

3) I har for brede rettigheder og for mange “stående” admin-konti

CISA fremhæver manglende adskillelse mellem admin- og brugerkonti som en af de typiske basisfejl. I praksis betyder det: én kompromitteret pc kan blive til fuld tenant-adgang.

Gør i stedet: adskil admin- og brugerkonti, brug “least privilege”, og indfør tidsbegrænset admin (PIM), så rettigheder kun aktiveres ved behov.

4) Offboarding fejler: “Zombie-konti” og gæsteadgange bliver stående

En tidligere medarbejder, en gammel ekstern konsulent eller en glemt servicekonto er en genvej uden alarmklokker. Det er sjældent et bevidst valg – det er en procesfejl.

Gør i stedet: koble HR-offboarding til IT: disable konto samme dag, fjern sessions, overfør OneDrive/Outlook, fjern gruppemedlemskaber, og afslut gæsteadgang efter udløb.

5) Backup-myten: I har backup, men I kan ikke gendanne under pres

Sophos beskriver, at angribere går efter at kompromittere/slette backups før de krypterer (State of Ransomware 2024). Derfor er “vi har backup i cloud” ikke et svar.

Gør i stedet: design backup efter angreb: immutable kopier, adskilt adgang (separat konto/tenant hvor relevant), og regelmæssige restore-tests af M365-data og kritiske servere/VM’er.

6) Patching og endpoint-styring halter (uadministrerede enheder)

Verizon DBIR peger på, at udnyttelse af kendte sårbarheder er vokset (2024). Hvis I har “endpoint sprawl” (uadministrerede enheder), får I huller, I ikke kan se (Data Magic, 2026).

Gør i stedet: gør Intune/endpoint management til adgangskrav: kun compliant devices må tilgå M365, og patching skal måles på dækning og alder på sårbarheder – ikke på “vi opdaterer en gang imellem”.

7) Security awareness er forældet i en tid med AI-phishing

Heimdal nævner phishing som en hyppig brud-vej (2026), og VikingCloud peger på, at mange SMB’er rammes af AI-genereret phishing (2026). Det gør “årlig quiz” til en dårlig kontrol.

Gør i stedet: kør korte, hyppige øvelser og bind dem til konkrete kontroller: rapporteringsknap i Outlook, blokering af farlige vedhæftninger/links (Defender for Office 365), og tydelige regler for deling af data til eksterne AI-værktøjer (Shadow AI).

Tjekliste: Sådan finder I jeres gentagelses-risiko på 30 dage

Brug tjeklisten som intern audit. Sæt en ansvarlig og en deadline på hvert punkt. Hvis I ikke kan svare “ja” med dokumentation, er det et hul.

Område	Kontrol (konkret)	Hvad I kigger efter	Minimumskrav
Identitet (Entra ID)	Conditional Access	Policies for admin, højrisiko og cloud-apps	Blokér legacy auth, kræv MFA, kræv compliant device hvor relevant
MFA	Phishing-resistant MFA	Hvem kan logge ind med “bare” app-prompt?	FIDO2/WHfB på admin + finans/CRM/HR
Rettigheder	Privileged access	Antal Global Admins og stående privilegier	Minimér GA, brug PIM og separate admin-konti
Offboarding	Automatiseret lukning	Gæster, tidligere ansatte, servicekonti	Disable samme dag + månedlig review + udløb på gæsteadgang
Backup & restore	Restore-test	Kan I gendanne M365-data og kritiske workloads hurtigt?	Test kvartalsvis, mål RTO/RPO, og beskyt backup mod sletning
Endpoint	Compliance og patching	Uadministrerede enheder og patch-lag	Intune compliance kræves for adgang; patch-SLA for kritiske sårbarheder
Incident Response	Runbook + logning	Hvem gør hvad de første 60 min? Hvilke logs har I?	Runbook, kontaktliste, bevis-sikring, og efteranalyse med handlingsplan

Sådan prioriterer I indsatserne uden at drukne i opgaver

Hvis I skal vælge, så start dér hvor én fejl giver størst effekt for angriberen:

1. Identitet først: Entra ID, MFA, Conditional Access. (Credentials er en hyppig startvektor, IBM 2024).
2. Rettigheder bagefter: færre admins, PIM, og strammere app-consent.
3. Restore-evne: I kan godt leve med et nedbrud. I kan sjældent leve med datatab og uger uden drift.
4. Endpoint/patching: luk kendte huller og få styr på uadministrerede enheder.
5. Træning + kontrol: awareness uden tekniske stopklodser giver for lidt.

Før → Efter #2
Før: Alle kan logge ind fra enhver enhed, og I opdager først problemet, når en konto misbruges.
Efter: I kræver compliant device for adgang til kerne-apps, og risky sign-ins udløser blokering/step-up. Resultat: færre “heldige” kompromitteringer og mindre oprydning efterfølgende.

FAQ: IT sikkerhed SMB og gentagne brud

Hvad er den mest typiske årsag til gentagne brud i en SMB?

At første hændelse bliver løst som en driftssag, ikke en sikkerhedssag: password reset og gendannelse – men ingen gennemgang af rettigheder, tokens, app-consent, regler og logs. Løsning: fast “post-incident” tjekliste med dokumenterede fund og ændringer.

Hvordan reducerer vi risikoen for phishing i Microsoft 365?

Kombinér adfærd og teknik: (1) træning i korte, hyppige forløb, (2) Defender for Office 365-politikker for links/vedhæftninger, og (3) rapporteringsknap i Outlook med en klar intern proces. Heimdal (2026) peger på phishing som en hyppig brudvej.

Er MFA nok længere, eller skal vi gøre mere?

MFA er stadig et minimum, men ikke et stopskilt mod token-tyveri og MFA-fatigue. Microsoft (2024) beskriver netop disse metoder. Tommelfingerregel: Admins og brugere med adgang til følsomme data skal have phishing-resistant MFA + Conditional Access, ikke kun SMS/app-prompt.

Hvad skal en incident response plan som minimum indeholde?

En kontaktliste (internt/eksternt), en 60-minutters runbook (isolér, bevar beviser, stop tokens/sessions, kommunikation), en log-liste (hvilke logs I skal kunne trække), og en “lukkeseddel” med rodårsag og forebyggende ændringer. Hvis planen ikke kan følges kl. 03:00, er den for kompleks.

Hvordan ved vi, om vores backup kan modstå ransomware?

Hvis samme admin kan slette både produktion og backup, er I sårbare. Sophos (2024) peger på, at angribere går efter backups før kryptering. Krav: immutable eller stærkt beskyttet backup + restore-test med målt RTO/RPO (hvor hurtigt og hvor meget data I mister).

Hvad er de første 3 M365-sikkerhedstiltag, der giver mest effekt?

(1) Slå legacy authentication fra og håndhæv MFA, (2) indfør Conditional Access for admin og kerne-apps, (3) ryd op i admin-roller og brug PIM. Det reducerer sandsynligheden for, at kompromitterede credentials (IBM 2024) bliver til fuld adgang.

Hjælper NIS2 krav SMB, hvis vi “bare” er underleverandør?

Ja, fordi kravene ofte lander i jeres kontrakter, audits og kundeforespørgsler længe før en myndighed banker på. ENISA (2024) peger på supply chain som en central trussel. Praktisk regel: Hvis I leverer drift, data eller adgang til større kunder, så skal I kunne dokumentere kontroller (identitet, backup, logging, IR) – også selv om I ikke er direkte omfattet.

Sådan implementerer I forbedringerne (konkret plan)

1. Uge 1: Kortlæg Entra ID: antal admins, MFA-status, legacy auth, og de 10 mest brugte cloud-apps.
2. Uge 2: Udrul Conditional Access for admins og højrisiko-brugere. Kræv phishing-resistant MFA for admin.
3. Uge 3: Ryd op i rettigheder: separate admin-konti, PIM, og luk app-consent for brugere (med godkendelsesflow).
4. Uge 4: Test restore: vælg 2 kritiske scenarier (mail/SharePoint og en kritisk server/VM). Mål RTO/RPO og luk slette-adgange til backup.
5. Efter 30 dage: Kør en mini-IR-øvelse: “phished konto” og “ransomware på endpoint”. Opdater runbook ud fra det, der faktisk gik galt.

Kilder: IBM Cost of a Data Breach Report 2024, Verizon DBIR 2024, Microsoft Digital Defense Report 2024, Sophos State of Ransomware 2024, Heimdal SMB-statistik 2026, ENISA Threat Landscape 2024, CISA CPG.

Relevante ydelser: IT-sikkerhed, Microsoft 365, Azure, drift, compliance.