Typer av phishing-attacker ni bör simulera

Att förstå angreppslandskapet är grunden för en meningsfull simulering. Här är de varianter som är mest relevanta för svenska organisationer:

En vanlig miss är att bara simulera generisk e-postphishing. I verkligheten är det de riktade attackerna – spear phishing och whaling – som orsakar störst skada. Ert simuleringsprogram bör spegla det.

Så utformar ni ett phishing-simuleringsprogram

Steg 1: Sätt tydliga mål och baslinjer

Innan ni skickar det första testmailet behöver ni definiera vad ni mäter och varför. De tre viktigaste KPI:erna:

• Klickfrekvens – andelen som klickar på den skadliga länken eller bilagan
• Rapporteringsgrad – andelen som aktivt rapporterar mailet (via en "Report Phish"-knapp eller till SOC)
• Kompromissfrekvens – andelen som faktiskt lämnar ifrån sig inloggningsuppgifter eller laddar ner en fil

Rapporteringsgraden är den mest underskattade mätpunkten. En organisation där 30 % klickar men 50 % rapporterar har ett starkare försvar än en där 10 % klickar men ingen rapporterar – eftersom den första organisationen genererar underrättelser som SOC kan agera på.

Steg 2: Välj verktyg och plattform

Marknaden erbjuder mogna plattformar för phishing-simulering:

• KnowBe4 – störst bibliotek av mallar, starkt rapporteringsstöd
• Proofpoint Security Awareness – integreras väl med Proofpoints e-postsäkerhet
• Cofense PhishMe – fokus på rapportering och incidentrespons
• Microsoft Attack Simulation Training – inbyggt i Defender for Office 365 Plan 2

Valet bör styras av er befintliga e-postplattform, organisationens storlek och om ni vill hantera programmet internt eller via en partner. Managerad molnsäkerhet

Steg 3: Designa realistiska scenarion

Generiska mallar ger generella resultat. De mest effektiva simuleringarna använder:

• Lokalt relevanta avsändare – Skatteverket, PostNord, Klarna, er egen IT-avdelning
• Tidsanpassning – deklarationsperiod, lönerevision, budgetcykel
• Rollbaserad anpassning – ekonomiavdelningen får en fakturarelaterad simulering, HR får en CV med makrovirus
• Varierande svårighetsgrad – börja med uppenbara indikationer (stavfel, konstig avsändardomän) och öka successivt till AI-genererade, kontextmedvetna meddelanden

Steg 4: Utbilda i anslutning till simuleringen

Här skiljer sig effektiva program från meningslösa. Den som klickar ska omedelbart mötas av en kort, konstruktiv utbildning – inte en skambeläggande varningssida. Forskning från bland annat KnowBe4 och SANS visar att utbildning som levereras inom sekunder efter felet har signifikant högre retention än generiska e-learningkurser som genomförs veckor senare.

Konkret innebär det:

1. Omedelbar "teachable moment" – en sida som visar exakt vilka varningssignaler som fanns i det specifika mailet

2. En kort mikro-utbildning (2–3 minuter) om den aktuella attacktypen

3. Uppföljande djupare modul för medarbetare som upprepade gånger missar simuleringar

Steg 5: Iterera och eskalera

Ett phishing-simuleringsprogram är inte ett projekt – det är en process. Vår rekommendation baserat på erfarenhet i Opsios SOC:

• Månad 1–3: Etablera baslinje med medelsvar scenarion. Mät utan att döma.
• Månad 4–6: Introducera svårare scenarion och rollbaserad anpassning. Börja mäta rapporteringsgrad aktivt.
• Månad 7–12: Lägg till spear phishing och smishing. Integrera resultat i säkerhetsöversikter till ledningen.
• Löpande: Kvartalsvis sammanställning, årlig programrevidering, koppling till incidentdata.

Tekniska kontroller som kompletterar simulering

Beteendeträning fungerar inte i ett vakuum. Parallellt med simuleringsprogrammet bör ni ha robusta tekniska skydd:

E-postautentisering

• SPF (Sender Policy Framework) – definierar vilka servrar som får skicka mail från er domän
• DKIM (DomainKeys Identified Mail) – kryptografisk signering av utgående mail
• DMARC (Domain-based Message Authentication) – policy för hur mottagande servrar ska hantera mail som misslyckas SPF/DKIM

Förvånansvärt många svenska organisationer har fortfarande DMARC på p=none, vilket innebär att obehöriga kan skicka mail som ser ut att komma från er domän utan konsekvens. Sätt p=reject som mål.

Kompletterande skydd

• Conditional Access och MFA – även om inloggningsuppgifter komprometteras via phishing, begränsar MFA skadan
• Safe Links / URL-rewriting – realtidsskanning av länkar i e-post
• Sandbox-detonering av bilagor – bilagor öppnas i isolerad miljö innan de når inkorgen
• DLP-policies – förhindrar att känslig data skickas ut som resultat av social engineering

Managerade molntjänster

NIS2 och regulatoriska krav

NIS2-direktivet, som trädde i kraft i EU och implementerats i svensk lagstiftning, ställer explicita krav på att organisationer inom berörda sektorer ska bedriva systematiskt arbete med säkerhetsmedvetenhet. Artikel 21 anger specifikt att åtgärder ska inkludera "cyberhygienrutiner och utbildning i cybersäkerhet".

Phishing-simulering ger er tre saker som tillsynsmyndigheter (i Sveriges fall MSB) vill se:

1. Dokumentation – mätbar data över tid som visar att ni aktivt arbetar med säkerhetskultur

2. Kontinuitet – inte en engångskurs utan ett löpande program

3. Åtgärdskedja – koppling mellan identifierad risk (hög klickfrekvens i viss avdelning) och konkret insats (riktad utbildning)

Under GDPR kan personuppgiftsincidenter orsakade av phishing medföra sanktionsavgifter. Integritetsskyddsmyndigheten (IMY) har i flera beslut noterat bristande tekniska och organisatoriska åtgärder som en försvårande omständighet. Att kunna visa att ni bedriver aktiv phishing-simulering stärker er position.

Vanliga misstag vi ser

Efter att ha hjälpt organisationer i olika storlekar att implementera simuleringsprogram har vi identifierat återkommande fallgropar:

Skambaserad kultur. Om folk bestraffas för att klicka skapar ni en kultur där ingen vågar rapportera misstag – exakt motsatsen till vad ni behöver. Phishing-simulering ska vara utbildning, inte övervakning.

Samma typ av simulering varje gång. Medarbetare lär sig att "ignorera alla mail med PostNord-logga den 15:e varje månad" istället för att utveckla genuint kritiskt tänkande.

Ingen koppling till incidenthantering. Simuleringsprogrammet lever i HR-avdelningens utbildningsplattform medan SOC lever i sin SIEM. Integrera "Report Phish"-funktionen med er incidentprocess.

Bara e-post. Smishing och vishing ökar, särskilt mot ledningsgrupper. Begränsa inte programmet till en enda kanal.

Ledningen undantas. VD:ar och CFO:er är primära mål för whaling – och ofta de mest motvilliga att delta i simuleringar. Det är precis därför de bör prioriteras.

Så mäter ni ROI på phishing-simulering

Säkerhetsinvesteringar är notoriskt svåra att mäta i kronor, men phishing-simulering ger ovanligt konkret data:

Koppla dessa siffror till era incidentdata. Om antalet phishing-relaterade ärenden i SOC minskar parallellt med simuleringsprogrammets mognad har ni ett starkt ROI-argument. Enligt Flexeras State of the Cloud har kostnadshantering konsekvent rankats som organisationers främsta utmaning – och oplanerade säkerhetsincidenter är en betydande dold kostnadsdrivare.

Cloud FinOps

Opsios perspektiv: vad vi ser i produktion

Vårt SOC i Karlstad och Bangalore hanterar säkerhetshändelser dygnet runt. Phishing-relaterade incidenter är en av de tre vanligaste kategorierna. Det vi ser skiljer sig ofta från vad kunder förväntar sig:

• BankID-relaterad phishing är påtagligt vanligare i Sverige än i andra marknader – angripare utnyttjar den höga tillit svenskar har till BankID
• Leverantörskedjephishing ökar – angripare komprometterar en leverantörs e-postkonto och skickar sedan autentiska meddelanden med skadliga bilagor
• AI-genererad phishing på svenska har gått från dåligt till övertygande på under två år

Att kunna koppla simuleringsprogrammets data till verklig hotinformation från SOC ger en feedbackloop som rent utbildningsfokuserade program saknar. Managerad molnsäkerhet

Vanliga frågor

Hur ofta bör man köra phishing-simuleringar?

Minst en gång i månaden, men med varierande svårighetsgrad och scenarion. Oregelbundna intervall ger mer realistisk data än fasta scheman, eftersom medarbetare annars lär sig att "det är dags igen". Komplettera med riktade simuleringar mot högriskgrupper kvartalsvis.

Är det lagligt att phishing-testa sina egna anställda i Sverige?

Ja, men det kräver transparens. Informera via policy att simuleringar förekommer, förankra med fackliga representanter om sådana finns, och säkerställ att resultaten hanteras som utbildningsunderlag – inte som disciplinära bevis. GDPR kräver att persondata från testerna hanteras med stöd i berättigat intresse eller samtycke.

Vilka verktyg används vanligast för phishing-simulering?

KnowBe4, Proofpoint Security Awareness och Cofense PhishMe är marknadsledande. Microsoft erbjuder Attack Simulation Training i Defender for Office 365. Valet beror på organisationens storlek, befintlig plattform och integrationsbehov. Ett verktyg utan tydlig process runtomkring ger dock begränsat värde.

Vad är en rimlig klickfrekvens att sikta på?

Nystartade program ser ofta klickfrekvenser på 20–35 %. Efter 12 månader av regelbunden simulering bör målet vara under 5 %. Viktigare än klickfrekvensen är dock rapporteringsgraden – hur stor andel som aktivt anmäler det misstänkta mailet till SOC eller IT.

Räcker phishing-simulering för att uppfylla NIS2:s krav på utbildning?

Nej, men det är en central komponent. NIS2 kräver bredare säkerhetsmedvetenhetsprogram som också täcker incidenthantering, fysisk säkerhet och leverantörsrisk. Phishing-simulering ger dock mätbar dokumentation som tillsynsmyndigheter uppskattar vid granskning.