Varför externa penetrationstester är affärskritiska

Hotbilden har förändrats

Ransomware-grupper och APT-aktörer (Advanced Persistent Threats) riktar sig alltmer mot publikt exponerade tjänster som ingångspunkt. En sårbar webbapplikation är ofta den första länken i en attackkedja som slutar med krypterade servrar och ett lösenkrav i Bitcoin.

Enligt Datadogs State of Cloud-rapport har molnadoption fortsatt att accelerera, vilket innebär att den externa attackytan för de flesta organisationer är betydligt större än den var för bara två–tre år sedan. Fler tjänster exponerade mot internet = fler potentiella ingångar.

Regulatoriska krav — NIS2 och ISO 27001

NIS2-direktivet, som trädde i kraft inom EU och påverkar svenska organisationer inom samhällsviktiga och viktiga sektorer, ställer explicita krav på riskhantering och säkerhetstestning. Artikel 21 kräver att organisationer vidtar "lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder" — och regelbundna penetrationstester är en av de mest konkreta sätten att uppfylla det kravet.

ISO/IEC 27001 (kontroll A.12.6 och A.18.2) förutsätter att organisationer genomför tekniska säkerhetsgranskningar, inklusive penetrationstester, som del av sitt ledningssystem för informationssäkerhet (ISMS).

Integritetsskyddsmyndigheten (IMY) har i flera tillsynsärenden lyft fram bristande teknisk testning som en faktor vid GDPR-sanktioner. Ett dokumenterat pentest-program visar tillsynsmyndigheter att ni tar säkerhetsarbetet på allvar.

Affärskontinuitet och kundförtroende

Bortom regelefterlevnad handlar det om att skydda verksamheten. En lyckad attack mot en publikt exponerad webbplats kan innebära:

• Driftstopp som kostar intäkter varje minut
• Dataläckage med GDPR-anmälningsplikt inom 72 timmar
• Varumärkesskada som tar år att reparera
• Leverantörskedjepåverkan om era system är integrerade med partners

Molnsäkerhet

Metodik: Så genomförs ett externt penetrationstest

Professionella pentester följer etablerade ramverk — vanligast är OWASP Testing Guide för webbapplikationer och PTES (Penetration Testing Execution Standard) för bredare tester. Här beskriver vi de faser som ett seriöst test alltid inkluderar.

Fas 1: Avgränsning och uppdragsdefinition (scope)

Innan en enda port skannas måste scope definieras. Det inkluderar:

• Vilka system som ska testas (domäner, subdomäner, IP-adresser, API-endpoints)
• Testtyp: black box (ingen förhandsinformation), grey box (viss information, t.ex. API-dokumentation) eller white box (full insyn)
• Rules of engagement: tider för testning, eskaleringsrutiner, kontaktpersoner
• Juridiskt avtal: skriftligt godkännande att testet får genomföras — utan detta är det tekniskt sett ett brott

Fas 2: Rekognosering (OSINT och teknisk kartläggning)

Testaren börjar med att samla information som en verklig angripare skulle göra:

• DNS-uppslagning: subdomäner, MX-poster, TXT-poster (SPF/DKIM/DMARC)
• Portskanningar: vilka tjänster lyssnar på vilka portar
• Teknologifingeravtryck: webbserver, CMS, ramverk, TLS-konfiguration
• OSINT: läckta credentials i publika databaser, exponerade Git-repositorier, metadata i publika dokument
• Certifikatstransparensloggar: identifierar subdomäner som organisationen kanske glömt bort

Fas 3: Sårbarhetsbedömning och analys

Med kartläggningen som grund identifierar testaren potentiella svagheter:

• OWASP Top 10 (2021-versionen, fortfarande branschstandard): Broken Access Control, Injection, Cryptographic Failures etc.
• Felkonfigurationer: öppna S3-buckets, exponerade admin-gränssnitt, default credentials
• Föråldrad mjukvara: opatchade CMS-plugins, gamla TLS-versioner
• API-specifika brister: BOLA (Broken Object Level Authorization), mass assignment, rate limiting-brister

Fas 4: Exploatering — bevis, inte teori

Här skiljer sig ett pentest från en skanning. Testaren utnyttjar aktivt identifierade sårbarheter för att bevisa att de är reella och visa vilken påverkan de har. Det kan innebära:

• SQL-injection för att extrahera databasinnehåll
• XSS (Cross-Site Scripting) för att kapa användarsessioner
• SSRF (Server-Side Request Forgery) för att nå interna resurser via webbapplikationen
• Kedjeangrepp: kombinera en mindre sårbarhet med en annan för att uppnå kritisk påverkan

Varje exploatering dokumenteras med skärmdumpar, HTTP-requests/responses och steg-för-steg-beskrivningar.

Fas 5: Rapportering — den viktigaste leveransen

En pentest-rapport som bara listar sårbarheter utan kontext är meningslös. En bra rapport innehåller:

Fas 6: Omtest (retest)

Efter att ni åtgärdat identifierade sårbarheter genomförs ett omtest för att verifiera att fixarna faktiskt fungerar. Vi ser regelbundet att hastigt implementerade patchar introducerar nya problem — omtestet fångar detta.

Vanliga misstag vi ser från SOC-perspektiv

Opsios SOC hanterar säkerhetshändelser dygnet runt. Här är mönstren vi observerar hos organisationer som blir angripna trots att de "gjort ett pentest":

1. Pentest som engångshändelse. Organisationen kör ett test inför en certifiering och gör sedan inget på 18 månader. Under den tiden har nya funktioner deployats, nya API-endpoints skapats och beroenden uppdaterats. Attackytan har förändrats — men säkerhetstestningen hänger inte med.

2. Bara automatiserade skanningar. Nessus, Qualys och Burp Suite i automatläge hittar kända CVE:er. De hittar inte att er lösenordsåterställningsfunktion tillåter account takeover via en IDOR-brist. Manuell testning krävs.

3. Ingen koppling till incidenthantering. Pentest-rapporten hamnar i en mapp. När SOC sedan larmar om en misstänkt aktivitet mot exakt den tjänst som var sårbar, saknas kontexten. Koppla pentest-resultaten till ert SIEM och era runbooks.

4. Scope som är för snävt. "Testa bara webbplatsen" — men angriparen hittar en exponerad Jenkins-instans på en subdomän som ingen visste om. Inkludera hela den externa attackytan i scope, inte bara huvuddomänen.

Managerade molntjänster

Molnspecifika överväganden

Om era webbapplikationer körs i AWS, Azure eller GCP tillkommer molnspecifika angreppsvektorer:

• Felkonfigurerade IAM-roller som exponeras via metadata-endpoints (SSRF → credential theft)
• Publika S3-buckets/Azure Blob Storage med känslig data
• Exponerade Kubernetes-dashboards eller API-servrar utan autentisering
• Secrets i miljövariabler som läcker via felmeddelanden

I AWS eu-north-1 (Stockholm) och Azure Sweden Central ser vi att organisationer ofta har bättre koll på sin on-prem-säkerhet än på sin molnkonfiguration. Molnleverantörernas shared responsibility-modell innebär att ni ansvarar för konfigurationen — inte AWS eller Azure.

Flexeras State of the Cloud har konsekvent visat att säkerhet är en av de främsta utmaningarna för molnanvändare, tillsammans med kostnadshantering. Det speglar vad vi ser i praktiken: organisationer som migrerar snabbt till molnet utan att anpassa sin säkerhetstestning.

Molnmigrering

Så väljer ni rätt leverantör för penetrationstest

Marknaden är full av aktörer som erbjuder "penetrationstester" men egentligen levererar en automatiserad skanning med en snygg rapport. Ställ dessa frågor:

• Vilka certifieringar har testarna? OSCP, OSCE, CREST eller motsvarande visar att testaren klarar praktiska exploateringsscenarier.
• Hur stor andel manuell testning ingår? Kräv att minst 60–70 % av testtiden är manuell.
• Ingår omtest? Om inte — gå vidare till nästa leverantör.
• Hur presenteras resultaten? Be om en exempelrapport. Om den bara listar Nessus-output har ni att göra med en skanner, inte en pentestare.
• Har leverantören erfarenhet av er bransch och era regelverk? En pentestare som förstår NIS2 och er verksamhetskontext levererar mer relevanta rekommendationer.

Managerad DevOps

Bygga ett löpande säkerhetstestprogram

Ett moget säkerhetsprogram förlitar sig inte på årliga pentester som enda testmetod. Kombinera:

Genom att integrera säkerhetstestning i er CI/CD-pipeline via SAST (Static Application Security Testing) och DAST (Dynamic Application Security Testing) fångar ni många brister redan under utveckling — innan de når produktion.

Cloud FinOps

Vanliga frågor

Hur ofta bör vi genomföra externa penetrationstester?

Minst årligen, plus efter varje större förändring i infrastruktur, ny funktionalitet i webbapplikationer eller vid byten av molnleverantör. NIS2 kräver regelbundenhet — dokumentera frekvens och resultat för att visa tillsynsmyndigheter att ni arbetar proaktivt.

Vad är skillnaden mellan en sårbarhetsskanning och ett penetrationstest?

En sårbarhetsskanning är automatiserad och identifierar kända brister (CVE:er) utan att försöka utnyttja dem. Ett penetrationstest går längre: en säkerhetsexpert försöker aktivt exploatera sårbarheterna, kedja ihop dem och visa verklig påverkan på verksamheten. Skanningen är ett hygienverktyg, pentestet är den verkliga stresstesten.

Räcker det med automatiserade verktyg som Nessus eller Qualys?

Nej. Automatiserade verktyg är bra som utgångspunkt, men de missar affärslogikbrister, felaktig behörighetshantering och komplexa kedjeangrepp. Kombinera alltid automatisering med manuell testning av erfarna pentestare för att få en realistisk riskbild.

Kan ett penetrationstest störa vår produktionsmiljö?

Med rätt avgränsning (scope) och kommunikation är risken minimal. Professionella pentestare arbetar med kontrollerade metoder och har alltid en eskaleringsplan. Tester mot produktionsmiljö bör schemaläggas utanför trafiktoppar, och ni bör ha en rollback-plan på plats.

Vad kostar ett externt penetrationstest?

Priset varierar kraftigt beroende på scope: en enkel webbapplikation kan kosta från cirka 50 000 SEK, medan ett bredare test av hela den externa attackytan inklusive API:er, DNS och molnkonfiguration ofta landar på 100 000–300 000 SEK. Jämför det med kostnaden för ett intrång — då är det en billig försäkring.