Säkerhet & testning

Så arbetar jag med externa, interna och assume-breach-test för att visa hur en angripare faktiskt kan ta sig in och röra sig vidare

17 feb. 2026
Så arbetar jag med externa, interna och assume-breach-test för att visa hur en angripare faktiskt kan ta sig in och röra sig vidare

När jag arbetar med penetrationstest tycker jag att det är viktigt att inte fastna i bara en del av attackytan. En angripare tänker sällan i isolerade silos. Därför vill jag också testa miljön på ett sätt som visar hur en verklig angreppskedja kan se ut.

Det är här externa test, interna test och assume-breach-scenarier blir särskilt värdefulla. Tillsammans ger de en betydligt tydligare bild av hur väl verksamheten står emot både första intrång och vidare spridning.

Externa test visar vad som möter angriparen först

I ett externt penetrationstest börjar jag där en extern angripare börjar: med internetåtkomliga ytor.

Jag tittar på vilka system, tjänster och applikationer som exponeras utåt och hur de beter sig från utsidan. Jag vill förstå vilka möjligheter en angripare har att få fotfäste, utnyttja svaga punkter eller störa verksamheten genom till exempel felkonfigurationer, svaga autentiseringsytor eller andra sårbarheter som inte borde vara tillgängliga.

För mig är ett externt test viktigt eftersom det ofta visar organisationens mest synliga risker. Det är här en angripare först letar efter vägar in, och det är här en brist ofta snabbt kan bli både teknisk och affärsmässig.

Interna test visar hur långt en angripare kan komma

Om någon väl har tagit sig in är nästa fråga mycket viktig: vad händer sedan?

Det är där interna penetrationstest blir avgörande. Här börjar jag inne i infrastrukturen och tittar på hur lätt det är att röra sig vidare, höja behörighet, nå andra system eller utnyttja svag segmentering och svag identitetshantering.

Jag tycker att interna test ofta ger väldigt värdefulla svar, eftersom de visar hur stora konsekvenserna kan bli av ett lyckat första intrång. En miljö kan se relativt stark ut utifrån, men ändå vara för öppen internt. Då kan ett mindre intrång växa snabbt.

Det här är också ett område där rekommendationer ofta blir mycket konkreta: bättre segmentering, stramare åtkomst, tydligare administrativa gränser, hårdare kontroll över privilegierade konton och bättre skydd av kritiska system.

Assume breach gör säkerhetsarbetet mer realistiskt

Jag tycker mycket om assume-breach-tänket, eftersom det utgår från en enkel men viktig tanke: vad händer om angriparen redan är inne?

Det är ett väldigt nyttigt sätt att arbeta, särskilt i miljöer där kunden vill testa specifika farhågor. Det kan handla om läckta VPN-uppgifter, en insider, komprometterad leverantörsåtkomst, en lyckad phishing-attack eller en annan väg där det första skyddslagret redan har passerats.

När jag arbetar med ett sådant scenario vill jag inte bara visa om något är möjligt. Jag vill visa hur långt det går att komma, vilka hinder som faktiskt finns, vilka som saknas och vad som skulle minska konsekvenserna om ett verkligt angrepp började på det sättet.

Det här ger ofta mycket starka och praktiska resultat, eftersom kunden får se hur den egna miljön reagerar under realistiska förutsättningar.

Jag tittar på identitet, segmentering och tillit mellan system

I interna och assume-breach-scenarier tittar jag särskilt noga på tre områden: identitet, segmentering och tillit.

Identitet handlar om hur enkelt det är att missbruka konton, höja behörigheter eller använda dåligt skyddade administrativa vägar.

Segmentering handlar om hur väl miljön är uppdelad. Kan klientnät nå servrar i onödan? Går det att ta sig mellan zoner som borde vara tydligare avgränsade? Är leverantörsåtkomst och fjärråtkomst rimligt begränsad?

Tillit handlar om hur system litar på varandra. I många miljöer finns det äldre eller alltför generösa relationer mellan system, tjänster och konton. Det kan göra att en angripare kan gå mycket längre än kunden först tror.

Det är här jag tycker att många av de mest värdefulla insikterna finns.

Jag vill visa attackkedjan, inte bara enskilda fynd

När jag arbetar med den här typen av test vill jag inte bara rada upp tekniska observationer. Jag vill visa kedjan.

Hur skulle en angripare börja? Vilken första åtkomst verkar mest realistisk? Vad skulle de sedan göra? Vilka kontroller stoppar dem, och vilka gör det inte? Hur nära går det att komma affärskritiska tillgångar?

När man ser kedjan blir risk mycket lättare att förstå. Det gör också att kunden får bättre beslutsunderlag. I stället för att se tio separata brister ser man hur de hänger ihop och varför vissa åtgärder ger mycket större effekt än andra.

Jag vill att rekommendationerna ska minska konsekvensen av nästa intrång

En viktig del för mig är att rekommendationerna inte bara ska “täppa till” en enskild teknisk svaghet. Jag vill att de ska minska konsekvensen av nästa intrångsförsök.

Det kan innebära att stärka segmentering, förbättra skyddet kring identiteter, separera administrativa konton tydligare, minska lateral rörelse, skärpa leverantörsåtkomst, öka loggning eller införa bättre upptäckt av avvikande beteende.

För mig är det ett starkt tecken på kvalitet när kunden efter testet står bättre rustad även om en angripare skulle lyckas ta sig förbi första skyddslagret.

Så vill jag arbeta med externa, interna och assume-breach-test

Jag vill arbeta med de här testerna som ett sätt att visa verklig motståndskraft, inte bara enskilda tekniska brister.

För mig är målet att kunden ska förstå: hur attackytan ser ut utifrån, hur miljön beter sig inifrån och hur stora konsekvenserna kan bli om en angripare faktiskt får fotfäste.

Det är så jag vill arbeta med externa, interna och assume-breach-test.

Författare
Daniel Ölund