Executive Summary
Mange SMV’er køber en pentest for at få ro i maven, men ender med en teknisk rapport, der ikke svarer på det, ledelsen faktisk vil vide: Kan en angriber få adgang til vores mail, påvirke vores betalingsflow og flytte penge, før nogen stopper det? Det er et forretningsproblem, ikke kun et IT-problem. Når Business Email Compromise og konto-overtagelser rammer, er skaden ofte direkte på drift, likviditet og tillid. Verizon DBIR peger igen på, at den menneskelige faktor indgår i et stort flertal af brud, og BEC er stadig en af de mest direkte veje til økonomisk tab. Kilde
Løsningen er ikke en større rapport. Løsningen er en målrettet pentest af jeres 2 til 3 vigtigste kronjuveler, typisk Microsoft 365 eller Google Workspace og jeres økonomi- eller betalingsflow. Formålet er at teste, om de kontroller, I allerede betaler for, faktisk virker i virkeligheden. Det gælder for eksempel MFA eller passkeys, mailbeskyttelse, stop-regler i økonomi og to-kanals verifikation ved ændring af leverandørbetalinger. NIST beskriver penetrationstest som en kontrolleret metode til at vurdere sikkerhed i praksis, og CISA anbefaler klare mål, scope og regler for testen, så resultaterne kan bruges til konkrete forbedringer. Kilde Kilde
Hvis du vil have værdi for ledelsen, så bed ikke bare om “en pentest”. Bed om et afgrænset forløb med et mini-scope, fem acceptkriterier i almindeligt dansk, en retest og et kort beslutningsnotat på én side. Så bliver testen et værktøj til prioritering, samarbejde med jeres IT-partner og bedre forretningskontinuitet. Hvis du vil læse mere om selve ydelsen, kan du se pentest og et supplerende sikkerhedstjek.
Hvorfor ledelsen skal teste mail og betaling først
I mange danske virksomheder er mailen den praktiske hovednøgle. Her ligger dialogen med kunder, leverandører, revisor, bank og kolleger. Hvis en angriber overtager en mailkonto eller kan sende troværdige mails på jeres vegne, er vejen kort til falske fakturaer, ændrede kontooplysninger eller hastebetalinger, der ser legitime ud. Det er netop derfor, at Microsoft 365 og Google Workspace ofte bør stå øverst i scope, når du planlægger en defensiv pentest.
Betalingsflowet er den anden kronjuvel. Her er spørgsmålet ikke kun, om nogen kan bryde ind i et system. Det afgørende er, om jeres proces stopper et realistisk svindelforsøg. Kan en medarbejder blive presset til at godkende en ændring af leverandørkonto på baggrund af en troværdig mail? Bliver callback faktisk gennemført? Bliver to-kanals kontrol fulgt, når hverdagen er travl? Den slags findes sjældent i en sårbarhedsscanning. Det kræver et aftalt og etisk testforløb, hvor både teknik og adfærd bliver vurderet i en kontrolleret ramme. CISA fremhæver netop, at en penetrationstest skal planlægges med klare mål og realistiske scenarier for at give mening. Kilde
Hvis din virksomhed arbejder med persondata i mail, økonomi eller kundedialog, er der også et compliance-lag. GDPR artikel 32 kræver passende tekniske og organisatoriske foranstaltninger. En målrettet test kan give bedre dokumentation for, om de foranstaltninger virker i praksis og ikke kun på papir. Kilde Hvis governance og modenhed også er på dagsordenen, kan det give mening at koble testen med en modenhedsanalyse.
Sådan vælger du et scope, der afspejler den risiko du faktisk frygter
Den klassiske fejl er at købe en bred pentest uden at afklare, hvad der egentlig skal bevises. Så får du mange fund, men få beslutninger. Start i stedet med to spørgsmål: Hvilket forretningsmæssigt tab frygter vi mest? Og hvilke systemer eller processer skal en angriber påvirke for at skabe det tab?
For en typisk SMV vil et godt mini-scope ofte være afgrænset til tre dele. Først jeres primære mail- og identitetsplatform, altså Microsoft 365 eller Google Workspace. Dernæst jeres økonomisystem eller den del af organisationen, hvor betalingsinstrukser bliver modtaget, kontrolleret og godkendt. Til sidst de vigtigste proceskontroller omkring ændring af betalingsoplysninger, hastebetalinger og godkendelse uden for normal rutine.
Formuler scopet i almindeligt dansk. For eksempel sådan her:
- Kan en angriber få eller misbruge adgang til en almindelig mailkonto via realistiske metoder, uden at sikkerhedskontroller reagerer i tide?
- Kan en falsk eller kompromitteret mail påvirke økonomifunktionen til at ændre betalingsoplysninger eller godkende en betaling, hvis medarbejderen følger den nuværende praksis?
- Kan jeres eksisterende stop-regler, MFA, mailbeskyttelse og verifikationsprocedurer standse forsøget, før der opstår tab?
Det lyder enkelt, og det er pointen. NIST SP 800-115 lægger vægt på planlægning, mål, metode og regler for engagement, før selve testen går i gang. OWASP’s testguide gør det samme for web og applikationer: Testen skal afspejle en realistisk trusselmodel og et klart aftalt scope, ellers bliver resultatet svært at omsætte. Kilde Kilde
Hvis jeres cloudopsætning er usikker fra start, kan det være spild at gå direkte til pentest. I de tilfælde kan et indledende sikkerhedstjek være den hurtigste vej til at få styr på opsætning og baseline.
Fem acceptkriterier ledelsen kan forstå og styre efter
En pentest bliver først et ledelsesværktøj, når succes og fiasko er defineret på forhånd. Ellers står du bagefter med fund, men uden tydelig retning. Her er fem acceptkriterier, som de fleste SMV’er kan bruge direkte eller tilpasse.
- Ingen enkeltstående brugerhandling må kunne føre til ændring af leverandørkonto eller hastebetaling uden en uafhængig kontrol i en anden kanal.
- Ingen almindelig mailkonto må kunne kompromitteres uden, at stærk loginbeskyttelse eller alarmer stopper eller opdager forsøget hurtigt.
- Domænet må ikke kunne misbruges troværdigt til spoofing uden, at mailkontroller som SPF, DKIM og DMARC reducerer risikoen. Hvis det område er relevant hos jer, kan du læse mere i denne guide om indlæg og på siden om sikkerhedstjek.
- Økonomifunktionen skal følge en dokumenteret stop-regel ved ændring af betalingsoplysninger, også når anmodningen ligner noget fra direktøren eller en kendt leverandør.
- Testen skal ende i en retest, hvor kritiske fund enten er lukket eller har en tydelig ejer, frist og accepteret risiko.
Det vigtige er ikke at skrive dem “sikkerhedsfagligt korrekt”. Det vigtige er, at ledelse, økonomi, IT-partner og eventuel leverandør forstår præcis, hvad der tæller som bestået. Så kan du også bruge dem i bestyrelsesrapportering, cyberforsikring og intern prioritering.
Hvad du konkret skal bede leverandøren om
Når du indhenter tilbud, bør du bede om mere end metode og timeestimat. Bed om et forløb, der matcher jeres forretning. CISA anbefaler, at penetrationstest bliver afgrænset med klare mål, regler og forventninger til leverancer. Det er især vigtigt, når scope rører mail, identitet og økonomiprocesser. Kilde
Et brugbart oplæg bør som minimum indeholde:
- Et klart scope med navngivne systemer, roller og processer
- Rules of engagement, herunder hvad der må testes, hvornår og hvem der skal orienteres
- Realistiske scenarier for BEC, konto-overtagelse og påvirkning af betalingsflow
- En rapport opdelt i forretningsrisiko, tekniske fund og anbefalede handlinger
- En retest inden for aftalt tidsrum
- Et beslutningsnotat på én side med de tre vigtigste ledelsesbeslutninger
Det sidste punkt bliver ofte glemt. Men netop et kort decision brief er forskellen på “vi har fået en rapport” og “vi har fået et beslutningsgrundlag”. Her bør der stå, hvad der skal besluttes nu, hvad der kan vente til næste kvartal, og hvilke risici ledelsen aktivt accepterer. Hvis du vil løfte den ledelsesmæssige del yderligere, er en workshop for ledelse og bestyrelse et oplagt supplement.
Retest er der, hvor værdien bliver synlig
Mange virksomheder stopper efter første rapport. Det er synd, for så måler du kun fejl, ikke forbedring. En retest gør det muligt at dokumentere, om kontrollerne nu virker i praksis. Det er her, testen bliver et forretningsværktøj. Har I for eksempel strammet loginbeskyttelsen i Microsoft 365, justeret mailkontroller, indført callback-krav og tydeliggjort stop-reglen i økonomi, så skal retesten vise, om det faktisk ændrer udfaldet.
NIST’s vejledning peger på, at sikkerhedstest giver størst værdi, når resultaterne bruges systematisk til forbedringer og opfølgning. Det gælder også i små organisationer. Du behøver ikke et stort program. Du behøver en enkel rytme: test, luk, retest, beslut. Kilde
Det giver også et bedre samarbejde med ekstern IT-partner eller MSP. I stedet for en generel diskussion om “sikkerhedsniveau” kan I tale om konkrete punkter: Hvilke kontroller fejlede? Hvem ejer ændringen? Hvornår tester vi igen? Hvis din virksomhed arbejder med løbende sikkerhedsforbedring, kan det passe godt sammen med Forkant™ som ramme for faste sikkerhedsopgaver.
Næste skridt: Lav en mini-brief på én side før du køber noget
Inden du bestiller en pentest, så saml ledelse, økonomi og IT-partner i 30 minutter og skriv en side med fire overskrifter: vores to til tre kronjuveler, vores vigtigste frygtede tab, vores fem acceptkriterier og hvem der skal modtage beslutningsnotatet. Det er ofte nok til at skære en upræcis test fra og få en øvelse, der faktisk hjælper jer med at prioritere.
Hvis du vil gøre det helt lavpraktisk, så start med disse tre spørgsmål i morgen: Hvilken mailplatform er vores vigtigste indgang til svindel? Hvor kan en falsk betalingsinstruks realistisk slippe igennem? Og hvilke kontroller vil vi have bevis for virker i praksis? Når de svar er på plads, giver en målrettet pentest langt mere værdi end endnu en standardrapport. Hvis du først vil have styr på opsætning og baseline, så begynd med et sikkerhedstjek.